מה יותר טוב? DB
-
@ש-ב-ח אמר במה יותר טוב? DB:
לצערי לא הבנתי שאלתך, אם אתה מתכוון כמה רשומות יש בטבלה התשובה היא מיליוני רשומות.
לא, אתה ציינת הפרש של100-1000 אבל לא ציינת כמה אחוז הם ממה שכן חוזר בכל מקרה. למשל אם אתה שולף 10K רשומות, והסינון חוסך אלף נוספים, זה 10 אחוז, וזה לא משמעותי מבחינת הקריאה מהדיסק. אבל אם הסינון מחזיר רק רשומה בודדת ובלעדיו יש עוד מאה, וזה עם אינדקס (כי אם לא אז דיסק יש בכל מקרה על כל הרשומות ורק אולי נחסך קצת זיכרון), אז חסכנו הרבה קריאה מהדיסק (99%).
@ש-ב-ח אמר במה יותר טוב? DB:
בהקשר לנקודה זאת אני מסכם לעצמי, שאם הקוד כדי לכתוב שאילתות ארוך מידי ומייגע אני יכול לוותר על זה ולתת לשרת לסנן. (אני משתמש בבונה שאילתות של לאראול עם יחסים רהוטים (בתרגום ללשה"ק) מה שגורם לקושי לעבור על כל יחס ולעדכן את ההתניות שלו).
בהחלט, אני עושה את זה הרבה פעמים.
-
@yossiz אמר במה יותר טוב? DB:
אני חושב שאפשר לעשות כלל בוהן שתמיד יותר לתת למסד לסנן מאשר לסנן בעצמך בקוד
אני גם חשבתי כך בתחילה אבל נתקלתי בבעיה שהוכרחתי לחשב מסלול מחדש...
כי הכלל נכון בתנאי שהשאילה לא מסובכת מידי שאילתה כזאת יכולה לקחת יותר מדקה בטבלה 2 מליון שורות (מנסיון)
אבל בצורה של הורדת כל הרשומות של החישוב ובלי מידי להתקשקש בעמודות נקבל את התוצאות השוות לשאילתה הזאת בשניה או פחות... (מנסיון) -
-
-
-
-
@dovid אמר במה יותר טוב? DB:
@OdedDvir האם where מעבר למה שהוא מצמצם שורות, הוא חוסך ביצועים?
למשל לא אכפת לי לקבל 100,000 שורות (אני בכל מקרה קורא רק את הראשון)
האם יש עניין לצמצם? במקרה של השואל היה מדובר בwhere שמצמצם את התוצאה ב90 אחוז.where לא עובר על כל השורות ומביא לך רק את מי שתואם?
ככה אני לתומי חשבתי. -
@ש-ב-ח בשאילתא שאתה מביא פה יש המון תתי שאילתות, אז אתה גורם ל-DB לעבור שוב ושוב על אותה טבלה. (למרות שלפום ריהטא, אם יש אינדקסים נכונים, השאילתה עדיין אמור להיות די זול).
קצת תמוה לי מאיפה לקחת את השאילתה שם, זה נראה קוד מכונה, לכאורה מיוצר על ידי ה-ORM של laravel? ולמה ה-ORM עושה כל התתי שאילתות? במקרה שם זה נראה מיותר לגמרי, היה אפשר לפשט הרבה את השאילתהעריכה: הבנתי למה צריך תתי שאילתה, (חשבתי מקודם שאפשר על ידי JOIN פשוט). אבל עדיין נראה לי שאפשר למטב מאוד את השאילתה שם באמצעות תת-שאילתה יחידה שמביאה את כל המטא דאטה בבת אחת (לא יודע כמה קל לבטא דבר כזה ב-eloquent ORM)
ועוד הערה: אם היית משתמש ב-API של וורדפרס לכאורה היית מקבל מן המוכן פונקציה שעושה שאילתה ממוטבת הדק היטב.
-
המשך,
ממילא אני חוזר שוב לנושא של אשכול זה:
אני שוב טוען, שאפשר להניח כלל אצבע, שתמיד עדיף לתת ל-DB לעשות את הסינונים/מיונים/ניתוחים מאשר לעשות לבד בקוד.
אבל זה בתנאי שמה שהיית עושה בקוד, זה בדיוק מה שאתה מבקש מה-DB לעשות, אבל אם בקוד היית עושה לולאה אחת על הדאטה, וב-SQL אתה מבקש מה-DB לעשות 120 לולאות, אז הדבר שונה.
אומנם, SQL היא שפה הצהרתית, ולכן אתה לא באמת אומר ל-DB מה לעשות, אלא מה התוצאה שאתה רוצה לקבל, ומנוע DB חכם מאוד, תמיד יבחר את דרך הפעולה היעילה ביותר, אבל מה לעשות והמנועים שלנו לא מספיק חכמים בכל המקרים.
@ש-ב-ח אמר במה יותר טוב? DB:
אני גם חשבתי כך בתחילה אבל נתקלתי בבעיה שהוכרחתי לחשב מסלול מחדש...
כי הכלל נכון בתנאי שהשאילה לא מסובכת מידי שאילתה כזאת יכולה לקחת יותר מדקה בטבלה 2 מליון שורות (מנסיון)
אבל בצורה של הורדת כל הרשומות של החישוב ובלי מידי להתקשקש בעמודות נקבל את התוצאות השוות לשאילתה הזאת בשניה או פחות... (מנסיון)אם אתה מסתמך על דוגמה זו, אז אני לא חושב שזו דוגמה מייצגת, כנ"ל
-
@yossiz אמר במה יותר טוב? DB:
אם היית משתמש ב-API של וורדפרס לכאורה היית מקבל מן המוכן פונקציה שעושה שאילתה ממוטבת הדק היטב
לא מכיר בAPI של וורדפרס אפשרות יחסים בין פוסט לפוסט ברמת המטא נתונים
@yossiz אמר במה יותר טוב? DB:
אבל עדיין נראה לי שאפשר למטב מאוד את השאילתה שם באמצעות תת-שאילתה יחידה שמביאה את כל המטא דאטה בבת אחת
ממש מעניין אותי, איך?
