26-12-11, 22:18
|
# 11 | |
|
חבר חדש
|
ציטוט:
בקשר למבזבז זמן ריצה? תרשה לי להגיד - "פחח" , תציף את הDB שלך ותעשה SELECT LIKE ותראה כמה זמן לוקח.. קח אתר נתונים עצום כמו פייסבוק, נשכח מהכמות שרתים המהירים שלהם והטכנולוגיה המתקדמת שלהם לחיפוש בשאילתות, בסופו של יום כאשר אתה מחפש שם משתמש לדוגמא הוא מחפש לך במאגרים עצומים ונותן לך את התוצאה תוך פחות משניה. אז לצאת ולהגיד שזה מבזבז זמן בשאילתות? שטויות. עוד דבר זה שנתונים של אנשים זה ממש לא זבל זה שימושי לכל אתר... פתאום אדם רוצה לשחזר פרופיל, מה הוא ירשם שוב? תשב בשקט חמודי  Last edited by blackghost; 26-12-11 at 22:22.. |
|
|
|
26-12-11, 23:24
|
# 12 |
|
אושיית הוסטינג
|
יותר מכל אני מעוניין ביעילות,
לכן לשמור נתונים של משתמש שלא רוצה להישאר, NOT ON MY DB.
__________________
אבי |
|
|
|
27-12-11, 10:50
|
# 13 |
|
חבר על
|
אם תקשר את ה-ID הראשי ל-UID (תקבע להם RELATIONS בין הטבלאות) אז במחיקת ID הראשי, כל השאר ימחקו.
מומלץ להשתמש בשיטה הזו באופן כללי בעיקר כדי למנוע את המצב המדובר בנושא הזה. |
|
|
|
27-12-11, 11:09
|
# 14 | |
|
Fatal Error
|
ציטוט:
שאילתת LIKE היא הפחות מומלצת מבין השאילתות שיכלת לבחור כיוון שהמשמעות שלה היא מעבר על כל השדות ב DB מתוך קליינט חיצוני. הדרך העדיפה יותר היא לייצור SP ולקרוא לו ע"מ לייבא את הנתונים. אם ה DB שלך מאונדקס (index) ובעל יכולת FTS - זכית, השאילתא תתקצר בהרבה יותר. כאשר מגיע משתמש ממומצע מן השורה ופותח אתר קטן, אין הכרח לשמור נתונים לאחור, שכן אם בחרתי למחוק את החשבון אז כנראה שאני לא אחזור שוב. לכן, מחיקת הנתונים מהמסד תחסוך לא רק מקום אלא גם כסף (מסד גדול = הרבה יותר כסף) וגם זמן (מסד קטן יותר = מעבר על כולו מהר יותר). אם בכל זאת אתה רוצה לשמור את הנתונים, עדיף לך לייצור טבלה נוספת במסד, תקרא לה למשל tblArchive שתהיה מראה לטבלה הראשית שלך. שם תשמור את כל נתוני הארכיון. איך תעביר את הנתונים? צור משימה מתוזמנת שתרוץ על המסד כל לילה ב 02:00 ותעביר לך את הרשומות. אגב, גם כאן, עדיף לייצר SP ומשימה מתוזמנת ב DB עצמו ולא בדף קליינט כדי לקצר זמני גישה. כשהטבלה המרכזית שאיתה אתה עובד קטנה יותר, אתה מצליח לעבור על כל הנתונים זריז יותר. העיקר רצית לצאת חכם, אלעד
__________________
eLad |
|
|
|
|
27-12-11, 11:39
|
# 15 | |
|
חבר חדש
|
ציטוט:
דבר שני, אתה יכול להתווכח עד מחר..אבל כמו שאמרתי אתר שמכבד את עצמו לא מוחק נתונים. לגבי מעבר לטבלה אחרת זה רעיון די טוב חוץ מהעובדה שאם תרצה להחזיר את המשתמש או את הנתונים לשמישות יכול להיות לך כפילויות נתונים שיגרמו לבעיות בשאילתות. |
|
|
|
|
27-12-11, 13:37
|
# 16 |
|
עסק רשום [?]
|
blackghost, אם לרגע אני אשתמש בצורת הדיבור שלך,
תרשה לי להגיד - "פחח". אם בעל האתר מעוניין למחוק מידע מסויים, כאשר הוא יודע מראש שהוא לא יצטרך אותו בעתיד או כאשר הוא מוחק אותו מתוך כוונה תחילה שלא יהיה ניתן לגשת אליו בעתיד, אין לו שום סיבה להשאיר אותו. האמירה שלך לא נכונה כבר מעצם העובדה העובדה שאתה קובע, להגיד "כל אתר לא צריך למחוק שום נתון" זה פשוט לא יכול להיות נכון. אתה לא יכול לדעת מה כל אתר שומר ואתה גם לא יודע מה כל אתר רוצה לעשות עם המידע שהוא שומר. סליחה על הביטוי אבל בקשר לדוג' המפגרת שלך על פייסבוק - הסיבה היחידה שהאתר באמת מצליח לשדר את המידע בצורה כזאת היא בגלל מערך שרתים גדול, אופטימיזציה איכותית וכלל הגורמים האחרים שהגדרת כ- "טכנולוגיה מתקדמת". אם לרגע נשכח מהנתון הזה כמו שאתה אומר ונפעיל את האתר בסביבה החדשה שתיארת בהתאם, תאמין לי שהוא לא יתפקד בצורה כזו ולמעשה לא יתפקד כלל. אני גם לא יודע מאיפה אתה מביא את המידע הזה שהם לא מוחקים כלום, אולי אתה אחד האנשים שאחראי לזה ואם כן אני חוזר בי, אני בכל אופן בטוח מאוד שיש נתונים שהם כן מוחקים (סביר להניח תיוגים שהוסרו לדוגמה). בקשר לשינוי בזמני הריצה שאתה מדבר עליו גם כן - בסופו של דבר אולי השינוי שירגיש משתמש בודד הוא מזערי. אבל ברגע שאנחנו מכפילים את זה בכמות ה- concurrently requests העתידית ולוקחים בחשבון את קצב הגדילה העתידי, השינוי שיהיה, יהיה גדול בהרבה, לא מדובר בהכרח אך ורק על זמני ריצה אלא גם על צריכה של משאבי מערכת. ובהמשך לתגובות הקצת יותר חכמות שקיבלת כאן, הביאו לך כמה דוגמאות טובות. AlonMi ציין שימוש ב- foreign keys. זה יכול להיות פתרון טוב, השאלה אם הוא מתאים לך ואם כן האם מבנה הטבלאות שלך בנוי נכון למימוש כזה. הייתי בהחלט מציע לבדוק את הפתרון הזה, זה יכול לספק לך תמורה טובה גם בכל הנוגע לזמני גישה בין הטבלאות המקושרות בתנאים המתאימים. קח בחשבון שזה דורש שהטבלאות שלך יעבדו תחת מנוע שונה מ- MyISAM (שבד"כ הוא מוגדר כברירת המחדל והוא לא תומך בזה), InnoDB הוא פתרון טוב רק מומלץ גם להכיר את ההבדלים בין השניים לוודא שאתה באמת בוחר באופציה הנכונה עבורך. eLad ציין שימוש בטבלה שתתפקד כארכיון לשמירת נתונים שכביכול "נמחקו". זה פתרון טוב, ניתן לממש את זה בכמה דרכים שונות כאשר כל אחת מותאמת למטרה קצת שונה, לא ארחיב יותר מדי כי ציינת שאתה לא מעוניין בזה בכל מקרה, רק תכיר שזה אפשרי ואם מדובר על מסד גדול ועמוס בד"כ באמצעות תכנון ומימוש נכון זה גם יהיה עדיף על פני הפתרון הקודם שהוצע המתאר שימוש בשדה פנימי שמהווה כ- FLAG הקובע האם השורה פעילה או מחוקה. Last edited by אדיר; 27-12-11 at 14:46.. סיבה: שגיאת כתיב |
|
|
|
27-12-11, 14:45
|
# 17 |
|
מנהל ראשי
|
המשתמש הבא שיחליט להתנהג בצורה שאינה מכובדת מול משתמשים אחרים ימצא את עצמו בחוץ.
|
|
|
|
27-12-11, 16:44
|
# 18 |
|
חבר חדש
|
אתה לא חייב לקחת את פייסבוק..
קח את האתר האישי שלך, תציף את הDATABASE בעזרת סקריפט PHP פשוט ותבצע שאילתת LIKE. אתה מוזמן למדוד זמנים ולרשום לי אחר כך אם צדקתי (רטורי)... לא תראה השפעה בזמני ביצוע. |
|
|
|
27-12-11, 16:47
|
# 19 | |
|
חבר חדש
|
ציטוט:
מצטער אם דברי פגעו במשהו הכל נאמר בהומור (ולכן צורף הסמיילי ) |
|
|
|
|
31-12-11, 20:23
|
# 20 | |
|
Fatal Error
|
ציטוט:
LIKE על מיליוני רשומות כפול מספר הדורשים את זה בו"ז יגרור האטה משמעותית לעומת מספר שורות בודדות שעליהם אתה רוצה לעשות LIKE. אגב כמו שכבר אמרתי, זו צורת השאילתא הכי פחות מומלצת.
__________________
eLad |
|
|
|
 |
| חברים פעילים הצופים באשכול זה: 1 (0 חברים ו- 1 אורחים) | |
| כלים לאשכול | |
| תצורת הצגה | |
|
|
עבור למצב קווי
