שאילתת Mysql לא תקינה
 

יש שאילתה שמאפשרת למשתמש למחוק את הפרופיל שלו מהמערכת,
אני מעוניין למחוק את השורה בכל טבלה שה-UID הוא 200.
הטבלאות במסד הן: signup, users_blocks, users_flags, users_online, users_prefs

ככה זה כתוב היום (וזה לא עובד) שאילתת מחיקה ליוזר מס' 20:
עזרתכם בנושא,
תודה
אבי

מה השגיאה?

לדעתי אתה אמור להגדיר בכל טבלה אידי

ניסיתי כל מיני וריאציות ולא הצלחתי,
לגבי השאילתה שלך:
אבי

לפי מיטב זכרוני זה סתם מסובך למחוק בשיטה שאתה רוצה..

עדיף לך לדחוס שאילתות במכה אחת, זה שונה מלשלוח אותן שוב ושוב.
ז"א

DELETE FROM signup WHERE UID = 200;DELETE FROM signup WHERE UID = 200;DELETE FROM table3 WHERE UID = 200;

* חשוב שתסיים את השאילתא ב ; ותתחיל אחת חדשה

בכל טבלה קיים השדה UID ? אם כן, בכל טבלה הוא זהה ל ID של ה USER ?

אני שואל כי זה הכי הגיוני, ומה ששגיא כתב פה אמור לעבוד.

כשמדובר בכמה טבלאות אתה צריך להוסיף בין ה DELETE ל FROM את שמות הטבלאות/שדות כמו בSELECT
DELETE `signup`.*, `asd`.* FROM `signup`, `asd`
WHERE `UID` = 200

http://dev.mysql.com/doc/refman/5.0/en/delete.html

למה שתרצה אגב למחוק נתון מהDATABASE?
אני פשוט עושה לו UPDATE לשדה STATUS 0.
אין למה למחוק שום נתון עדיף לשמור .

מה אתה מדבר שטויות...
כאשר אין שימוש בנתון נחוץ למחוק אותו כמובן
מה הקטע בלשמור "זבל" על המסד נתונים?
מבזבז זיכרון ומעלה את זמן הריצה של השאילתות על הטבלה בצורה ניכרת.

תעשה מה שאתה רוצה , אני רק אומר לך שכל אתר שמכבד את עצמו לא מוחק נתונים מהבסיס נתונים שלו.. לא YAD2 לא פייסבוק לא פורומים ולא כלום..

בקשר למבזבז זמן ריצה? תרשה לי להגיד - "פחח" , תציף את הDB שלך ותעשה SELECT LIKE ותראה כמה זמן לוקח..

קח אתר נתונים עצום כמו פייסבוק, נשכח מהכמות שרתים המהירים שלהם והטכנולוגיה המתקדמת שלהם לחיפוש בשאילתות, בסופו של יום כאשר אתה מחפש שם משתמש לדוגמא הוא מחפש לך במאגרים עצומים ונותן לך את התוצאה תוך פחות משניה.
אז לצאת ולהגיד שזה מבזבז זמן בשאילתות? שטויות.

עוד דבר זה שנתונים של אנשים זה ממש לא זבל זה שימושי לכל אתר...
פתאום אדם רוצה לשחזר פרופיל, מה הוא ירשם שוב?

תשב בשקט חמודי :)

יותר מכל אני מעוניין ביעילות,
לכן לשמור נתונים של משתמש שלא רוצה להישאר, NOT ON MY DB.

אם תקשר את ה-ID הראשי ל-UID (תקבע להם RELATIONS בין הטבלאות) אז במחיקת ID הראשי, כל השאר ימחקו.

מומלץ להשתמש בשיטה הזו באופן כללי בעיקר כדי למנוע את המצב המדובר בנושא הזה.

אם כבר ענייני יעילות,
שאילתת LIKE היא הפחות מומלצת מבין השאילתות שיכלת לבחור כיוון שהמשמעות שלה היא מעבר על כל השדות ב DB מתוך קליינט חיצוני. הדרך העדיפה יותר היא לייצור SP ולקרוא לו ע"מ לייבא את הנתונים. אם ה DB שלך מאונדקס (index) ובעל יכולת FTS - זכית, השאילתא תתקצר בהרבה יותר.

כאשר מגיע משתמש ממומצע מן השורה ופותח אתר קטן, אין הכרח לשמור נתונים לאחור, שכן אם בחרתי למחוק את החשבון אז כנראה שאני לא אחזור שוב. לכן, מחיקת הנתונים מהמסד תחסוך לא רק מקום אלא גם כסף (מסד גדול = הרבה יותר כסף) וגם זמן (מסד קטן יותר = מעבר על כולו מהר יותר).

אם בכל זאת אתה רוצה לשמור את הנתונים, עדיף לך לייצור טבלה נוספת במסד, תקרא לה למשל tblArchive שתהיה מראה לטבלה הראשית שלך. שם תשמור את כל נתוני הארכיון. איך תעביר את הנתונים? צור משימה מתוזמנת שתרוץ על המסד כל לילה ב 02:00 ותעביר לך את הרשומות. אגב, גם כאן, עדיף לייצר SP ומשימה מתוזמנת ב DB עצמו ולא בדף קליינט כדי לקצר זמני גישה.

כשהטבלה המרכזית שאיתה אתה עובד קטנה יותר, אתה מצליח לעבור על כל הנתונים זריז יותר.

העיקר רצית לצאת חכם,

אלעד

נתתי דוגמת LIKE לשאילתה הכי ארוכה, הדוגמה ניתנה על מנת שתעשה השוואה ותראה שאין שום שוני בזמני הביצוע שמורגש מבחינת המשתמש.
דבר שני, אתה יכול להתווכח עד מחר..אבל כמו שאמרתי אתר שמכבד את עצמו לא מוחק נתונים.
לגבי מעבר לטבלה אחרת זה רעיון די טוב חוץ מהעובדה שאם תרצה להחזיר את המשתמש או את הנתונים לשמישות יכול להיות לך כפילויות נתונים שיגרמו לבעיות בשאילתות.

blackghost, אם לרגע אני אשתמש בצורת הדיבור שלך,
תרשה לי להגיד - "פחח".

אם בעל האתר מעוניין למחוק מידע מסויים,
כאשר הוא יודע מראש שהוא לא יצטרך אותו בעתיד או כאשר הוא מוחק אותו מתוך כוונה תחילה שלא יהיה ניתן לגשת אליו בעתיד, אין לו שום סיבה להשאיר אותו.
האמירה שלך לא נכונה כבר מעצם העובדה העובדה שאתה קובע, להגיד "כל אתר לא צריך למחוק שום נתון" זה פשוט לא יכול להיות נכון.
אתה לא יכול לדעת מה כל אתר שומר ואתה גם לא יודע מה כל אתר רוצה לעשות עם המידע שהוא שומר.

סליחה על הביטוי אבל בקשר לדוג' המפגרת שלך על פייסבוק -
הסיבה היחידה שהאתר באמת מצליח לשדר את המידע בצורה כזאת היא בגלל מערך שרתים גדול, אופטימיזציה איכותית וכלל הגורמים האחרים שהגדרת כ- "טכנולוגיה מתקדמת".
אם לרגע נשכח מהנתון הזה כמו שאתה אומר ונפעיל את האתר בסביבה החדשה שתיארת בהתאם, תאמין לי שהוא לא יתפקד בצורה כזו ולמעשה לא יתפקד כלל.
אני גם לא יודע מאיפה אתה מביא את המידע הזה שהם לא מוחקים כלום, אולי אתה אחד האנשים שאחראי לזה ואם כן אני חוזר בי, אני בכל אופן בטוח מאוד שיש נתונים שהם כן מוחקים (סביר להניח תיוגים שהוסרו לדוגמה).

בקשר לשינוי בזמני הריצה שאתה מדבר עליו גם כן -
בסופו של דבר אולי השינוי שירגיש משתמש בודד הוא מזערי.
אבל ברגע שאנחנו מכפילים את זה בכמות ה- concurrently requests העתידית ולוקחים בחשבון את קצב הגדילה העתידי,
השינוי שיהיה, יהיה גדול בהרבה, לא מדובר בהכרח אך ורק על זמני ריצה אלא גם על צריכה של משאבי מערכת.

ובהמשך לתגובות הקצת יותר חכמות שקיבלת כאן, הביאו לך כמה דוגמאות טובות.

AlonMi ציין שימוש ב- foreign keys.
זה יכול להיות פתרון טוב, השאלה אם הוא מתאים לך ואם כן האם מבנה הטבלאות שלך בנוי נכון למימוש כזה.
הייתי בהחלט מציע לבדוק את הפתרון הזה, זה יכול לספק לך תמורה טובה גם בכל הנוגע לזמני גישה בין הטבלאות המקושרות בתנאים המתאימים.
קח בחשבון שזה דורש שהטבלאות שלך יעבדו תחת מנוע שונה מ- MyISAM (שבד"כ הוא מוגדר כברירת המחדל והוא לא תומך בזה), InnoDB הוא פתרון טוב רק מומלץ גם להכיר את ההבדלים בין השניים לוודא שאתה באמת בוחר באופציה הנכונה עבורך.

eLad ציין שימוש בטבלה שתתפקד כארכיון לשמירת נתונים שכביכול "נמחקו".
זה פתרון טוב, ניתן לממש את זה בכמה דרכים שונות כאשר כל אחת מותאמת למטרה קצת שונה,
לא ארחיב יותר מדי כי ציינת שאתה לא מעוניין בזה בכל מקרה, רק תכיר שזה אפשרי ואם מדובר על מסד גדול ועמוס בד"כ באמצעות תכנון ומימוש נכון זה גם יהיה עדיף על פני הפתרון הקודם שהוצע המתאר שימוש בשדה פנימי שמהווה כ- FLAG הקובע האם השורה פעילה או מחוקה.

המשתמש הבא שיחליט להתנהג בצורה שאינה מכובדת מול משתמשים אחרים ימצא את עצמו בחוץ.

אתה לא חייב לקחת את פייסבוק..
קח את האתר האישי שלך, תציף את הDATABASE בעזרת סקריפט PHP פשוט ותבצע שאילתת LIKE.
אתה מוזמן למדוד זמנים ולרשום לי אחר כך אם צדקתי (רטורי)...
לא תראה השפעה בזמני ביצוע.

אתה צודק, נסחפתי פה בהתבטאויות.
מצטער אם דברי פגעו במשהו הכל נאמר בהומור (ולכן צורף הסמיילי :) )

תהיה השפעה אדירה.
LIKE על מיליוני רשומות כפול מספר הדורשים את זה בו"ז יגרור האטה משמעותית לעומת מספר שורות בודדות שעליהם אתה רוצה לעשות LIKE. אגב כמו שכבר אמרתי, זו צורת השאילתא הכי פחות מומלצת.

יכולים להיות הפרשים אדירים בזמני הביצוע, הם מושפעים ותלויים גם בהמון גורמים שלוקחים בחשבון בעת תכנון ויצירת מסד הנתונים (ולא פחות חשוב גם צורת העבודה מולו),
לזרוק השערות באוויר זה לא נכון ולא אחראי.
אני בטוח שאם תקרא ותלמד קצת יותר על MySQL ותרד לעומק הדברים בסופו של דבר תבין שאתה טועה.

נ.ב
אני באמת שמח ששמת לב שההתבטאויות שלך כאן וגם בכמה בנושאים אחרים ממש לא היו במקום,
אולי זה נאמר בהומור - אבל מצחיק זה ממש לא היה.