ABA
יומן פעילות לוח שנה מבזקי חדשות תקנון RSS כותרות כותרות לפי תגובה ניקוי קוקיז IP להורדת אפליקציה
eBay AliExpress GearBest Amazon Booking Kiwi SkyScanner Trip Advisor


"מחפש ייעוץ בפתרון אלגוריתמי לתכנון DB ב SQL"
גירסת הדפסה        
קבוצות דיון בניית אתרים נושא #14750 מנהל    סגן המנהל    מפקח   Winner    צל"ש   מומחה  
אשכול מספר 14750
lior066

   11:15   12.01.09   
אל הפורום  
  מחפש ייעוץ בפתרון אלגוריתמי לתכנון DB ב SQL  
 
   מה המצב אנשים , אני בדילמה..

אני צריך לתכנן משהו בסגנון הזה:
יש לי 3 טבלאות עיקריות:
1. אומנים
2. אלבומים
3. שירים

אני רוצה עכשיו לתת למשתמש את האפשרות לשמור לעצמו דבר כזה:
1. רשימת אומנים אהובים.
2. רשימת אלבומים אהובים.
3. רשימת שירים אהובים.

עכשיו בעיקרון יש לי כמה כיוונים , אבל כל כיוון לוקח אותי לדרך אחרת לגמרי.

א. אני יכול לעשות 3 טבלאות קישורים שהם בנויות כך:


Key|Index [ID]
[UserID]
[ArtistID]

וכך לכל השאר ( אלבומים , שירים)

ב. אני יכול לעשות מין סטרינג מחובר שהוא כזה:


[userID;;1,4,65,86,4,98;;35,3,2,5,7;;234,65,21,45]

ואז אני אצטרך לעשות ספליט על השרת ולקרוא מהמסד נתונים את התוצאה.

ג.אני יכול לעשות היבריד של א' ו ב' כלומר 3 טבלאות שבתוכן יש לי אי די וכל זה ובVALUE לעשות את החיבור סטרינגים של הרשימה של כל אחד ואחד מהדברים.

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

יש למישהו רעיון , משהו יותר יצירתי?


                                שתף        
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

  האשכול     מחבר     תאריך כתיבה     מספר  
  הרעיון הראשון שלך הוא לא טוב , akoka 12.01.09 14:08 1
     גם אתה עברת על חוק מאוד חמור של נרמול... Ice Cold  12.01.09 15:08 2
         חח תקרא שוב מה כתבתי , akoka 12.01.09 15:15 3
  טוב הפתרון שעשיתי הוא כזה.. lior066 13.01.09 08:47 4
     אל תעשה את זה ככה... Ice Cold  13.01.09 11:42 5
     סתם רעיון djME 13.01.09 17:25 6
         אני מכיר את השיטה הזאת .. lior066 13.01.09 23:51 7
  מה אם...? lior066 16.01.09 05:43 8
     אני אומר שתקרא מהר מהני נתונים... הרעיון הזה הוא אולי Ice Cold  16.01.09 13:58 9
     אמ.. djME 16.01.09 14:18 10
  הרעיון הכי טוב לדעתי.... CaTz 18.01.09 19:53 11
  אל תתחשב ביעילות Sn00py  19.01.09 15:25 12

       
akoka

   14:08   12.01.09   
אל הפורום  
  1. הרעיון הראשון שלך הוא לא טוב ,  
בתגובה להודעה מספר 0
 
   אל תנסה לחסוך בטבלאות באמצעות פגיעה בחוקי נרמול טבלאות בסיסיים ,

או שתיצור טבלה אחת של מעודפים ,ותשים בה שדה Type שיהיה מסוג Enum ויכיל בתוכו 3 אופציות Artist/Album/Song

מבנה הטבלה

fav_id
fav_user_id
fav_type

משו כזה.

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


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Ice Cold  לחץ כאן להצגת דירוג המשתמש
חבר מתאריך 3.8.02
28041 הודעות, 19 פידבק		   15:08   12.01.09   
אל הפורום  
  2. גם אתה עברת על חוק מאוד חמור של נרמול...  
בתגובה להודעה מספר 1
 
למה שתרצה להגדיל את הטבלה שלך פי 3 שלא לצורך?
למה לא להשתמש ב-3 טבלאות שונות?


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
akoka

   15:15   12.01.09   
אל הפורום  
  3. חח תקרא שוב מה כתבתי ,  
בתגובה להודעה מספר 2
 
   ערכתי לאחרונה בתאריך 12.01.09 בשעה 15:15 בברכה, akoka
 
אתה לא עובר על שום חוק נרמול אם אתה עושה את זה בדרך שכתבתי,ושוב הצעתי גם את הרעיון לעשות את זה בטבלאות נפרדות.

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

נ.ב

הרעיון שלי היה כמו שיש לך פורום ,וטבלה להודעות בפורום ,אז זה בדיוק אותו דבר

יש לך משתמש ,ויש לך טבלה של העדפות של משתמש.

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


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
lior066

   08:47   13.01.09   
אל הפורום  
  4. טוב הפתרון שעשיתי הוא כזה..  
בתגובה להודעה מספר 0
 
   בסופו של דבר עשיתי הייברייד להייברייד

בניתי טבלה אחד עם השדות הבאות:


ID
USERNAME
FAVARTISTS
FAVALBUMS
FAVPLAYLIST

בעת יצירת משתמש \ הרשמה. הטבלה אוטומטית תבנה את אותו שורה עם ערכים של 0 בשדות של המועדפים.

בשדות של ה FAV אני עושה שרשור של ID והפרדה על ידי פסיק.
לאחר המשיכה אני יכול לבנות שאילתה על ידי בנייה של משפט IN ב SQL שככה יחסוך לי במקום במסד נתונים.

( שאלה לי למבינים, מבחינת SQLSERVER , מה עדיף היה לעשות , שאני יבנה שורה שורה וימשוך עם SELECT אחד אבל מלא מלא שורות , או להשתמש ב IN , בעיקרון אני יכול להבחין שה IN אינו כזה יעיל , אבל המטרה שלי היא לחסוך במקום כי אם נגיד האתר מגיע לרמה סתם של 20000 חברים , אני נדפק מבחינת מקום , אבל מבחינת IN אני לא יודע איך זה עובד, מה הסיבוכיות של האלגוריתם אם אתם יודעים? )

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

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

אני עדיין לא סגור על הפתרון שלי.

חשבתי על עוד פתרון על הדרך אבל הוא מורכב מידי להסביר עכשיו, וגם ככה התגובה ארוכה


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Ice Cold  לחץ כאן להצגת דירוג המשתמש
חבר מתאריך 3.8.02
28041 הודעות, 19 פידבק		   11:42   13.01.09   
אל הפורום  
  5. אל תעשה את זה ככה...  
בתגובה להודעה מספר 4
 
מה יקרה אם תצטרך לנהל את זה? למשל, להוריד מועדף אחד ולהוסיף אחר?

תתחיל לחתוך מחרוזות ?

לא מומלץ.


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
djME

   17:25   13.01.09   
אל הפורום  
  6. סתם רעיון  
בתגובה להודעה מספר 4
 
   מכיר bitwise?

אם אל אני אנסה להסביר
כל מועדף הוא בעל id משלו רק שכאן ה id הוא יהיה תוצאה של מספר בחזקת 2
זאת אומרת במקום בדרך כלל מספר רץ 1,2,3,4,5,6,7,8 יהיה לך: 2,4,8,16,32,64 וכו

אני יציג דוגמת טבלה:


ID   |   Favorite
======
1        tennis
2        football
4        basketball
8        swimming
16       dancing
32       sleeping
64       eat

עכשיו לכל יוזר יהיה תא: FAVARTISTS
עכשיו בוא נגיד שאני הוא יוזר ואני אוהב טניס, לשחות ולאכול: אז המספר שאני ישים בתא הוא 73

עכשיו אתה שואל איך ממספר 73 אני יודע איזה תחביבים יש ליוזר
אז התשובה נורא פשוטה
אתה מחזיק מערך של על סוגי התחביבים שיש
ואתה רץ בלולאה ככה שאתה לוקח את המספר 73 ועושה לו אנד (&) עם כל id של תחביב במידה וקיבלת true סימן שהתחביב הזה שייך ליוזר

ככה אתה יכול לנהל את הכל בצורה פשוטה מאוד

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

במידה ותצטרך עוד עזרה שאל

מקווה שלא עשיתי לך סבטוחה בראש


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
lior066

   23:51   13.01.09   
אל הפורום  
  7. אני מכיר את השיטה הזאת ..  
בתגובה להודעה מספר 6
 
   ערכתי לאחרונה בתאריך 13.01.09 בשעה 23:54 בברכה, lior066
 
אבל זה לא רלוונטי למקרה שלי , אני עובד מול מסד נתונים , הקטע הוא שכל אומן מיוצג על ידי ID במסד נתונים , ( המסד הזה אמור לגדול בצורה משמעותית .. ) ואני לא יכול להשים טיפוס דצימלי בישביל לשמור את ה ID זה יהיה משונה.. אני אצטרך כל פעם להגדיל את ה ID בחזקת 2, תאר לך שיש לי 1000 אומנים, אז מה..?

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

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

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

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

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


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
lior066

   05:43   16.01.09   
אל הפורום  
  8. מה אם...?  
בתגובה להודעה מספר 0
 
   ערכתי לאחרונה בתאריך 16.01.09 בשעה 05:45 בברכה, lior066
 
אם אני אצור טבלה חדשה עבור כל יוזר שנרשם, כמה שזה נשמע כבד, דווקא זה לא אמור להיות כזה בלאגן, נכון זה ייקח המון מקום אבל מבחינת אופטימיזציה זה נראה לי הכי נכון לעשות דבר שכזה.

כל יוזר נפתחת לו טבלה, הטבלה מיישמת טבלת מפתחות רגילה, כלומר יהיה המבנה הזה בכל טבלה:


id
dataType - EnumType - 1.Artist ,2.album, 3.singls
valueType - ה-ID של אותו סוג

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

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


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Ice Cold  לחץ כאן להצגת דירוג המשתמש
חבר מתאריך 3.8.02
28041 הודעות, 19 פידבק		   13:58   16.01.09   
אל הפורום  
  9. אני אומר שתקרא מהר מהני נתונים... הרעיון הזה הוא אולי  
בתגובה להודעה מספר 8
 
הרעיון הכי גרוע ששמעתי, עם כל הכבוד...

לכל יוזר טבלה? איפה נשמע דבר כזה? איך תנהל דבר כזה?


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
djME

   14:18   16.01.09   
אל הפורום  
  10. אמ..  
בתגובה להודעה מספר 8
 
   לא היה ולא נברא רעיון כזה
פשוט רעיון גרוע (סליחה על התוקפנות)

לא נוח לניהול לא יעיל לא ריאלי

בקיצור אל תעשה את זה


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
CaTz
חבר מתאריך 2.10.04
14537 הודעות		   19:53   18.01.09   
אל הפורום  
  11. הרעיון הכי טוב לדעתי....  
בתגובה להודעה מספר 0
 
   תצור 3 טבלאות נושא, + 3 טבלאות של קישורים

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

אם אתה רוצה לחפש מידע אודות השיטה, תחפש Many to Many

http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=xkw&q=Many+to+Many+mysql&btnG=Search
זה פשוט מדהים עד כמה שזה יעיל ופשוט!


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד
Sn00py 
חבר מתאריך 1.8.02
2954 הודעות		   15:25   19.01.09   
אל הפורום  
  12. אל תתחשב ביעילות  
בתגובה להודעה מספר 0
 
   חוץ מלעשות דברים באמת לא הגיוניים וחריגים(כמו לעשות טבלה לכל יוזר), תלך על המודל הפשוט ביותר שאתה יכול לעבוד עליו. אחר כך, תעשה אופטימיזציות אם צריך.
ההבדל ביעילות לעומת היכולת תחזוקה שלך ושל התכניתנים שיבואו אחריך פשוט מזערית.

\x6C\x65\x65\x74\x68\x61\x78\x30
\x72\x3A\x2D\x29
tresp4sser


                                                         (ניהול: מחק תגובה)
מכתב זה והנלווה אליו, על אחריות ועל דעת הכותב בלבד

תגובה מהירה  למכתב מספר: 
 
___________________________________________________________________

___________________________________________________________________
למנהלים:  נעל | תייק בארכיון | מחק | העבר לפורום אחר | מחק תגובות | עגן אשכול
       



© כל הזכויות שמורות ל-רוטר.נט בע"מ rotter.net