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

[blackghost]

נכתב במקור על ידי daNN

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

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

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

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

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

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

[Kernel]

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

[AlonMi]

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

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

[eLad]

נכתב במקור על ידי blackghost

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

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

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

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

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

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

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

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

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

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

אלעד

[blackghost]

נכתב במקור על ידי eLad

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

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

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

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

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

אלעד

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

[אדיר]

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

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

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

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

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

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

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

[דניאל]

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

[blackghost]

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

[blackghost]

נכתב במקור על ידי דניאל

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

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

[eLad]

נכתב במקור על ידי blackghost

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

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