תאוריה ומציאות

[guznik]

תאוריה ומציאות

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

 

[אורן עיני]

Nil ref error

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

 

[ייוניי]

לא הבנתי למה

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

 

[hg1979]

נראה לי

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

 

[arnonrgo]

כמה דברים

1. הנושא של מפתח surrogate (שאינו קשור לdata) הוא לא אחד מחוקי הנרמול למרות שהוא בד"כ עצה טובה לעיתים יש מפתחות "טבעיים" שהם מספיק טובים מספר אישי, ת"ז וכו 2. גם המלטצה זו וגם חוקי הנרמול הם עזרים שבאים להבטיח את העבודה שלנו כאשר יודעים מה עושים ומבינים את התוצאות ומשמעויות אפשר להפר כל "חוק" כזה דוגמא הכי נפוצה הם datamarts חוקי העיצוב שלהם אחרים לגמרי מחוקי הנרמול ומידע בגלל הרצון לקבל ביצועים בשאילתות ההבנה היא שהמידע הוא בעיקרו לקריאה בלבד והמעבר מהמידע האופרטיבי למידע בdatamart נעשה באופן מודע ומסודר ארנון

 

[עידו פ]

-->

ראשית, כפי שאמרו - אין משמעות של ביצועים אם ה-PK מוגדר כמפתח חסר משמעות או שה-PK מוגדר על עמודת מפתח בעלת משמעות (אם כי PK לרוב עדיף שיהיה על עמודה מספרית, ככה לפחות לימדו אותי). תמיד אפשר לאחר מכן להגדיר אינדקסים על שדות המפתח (ועוד יותר טוב - unique index מאחר ובין כה המפתחות הם חד-ערכיים) ולקבל את הביצועים של PK. שנית, לגבי האם PK צריך להיות נטול משמעות אפליקטיבית - אכן עדיף שהוא יהיה נטול משמעות ואני אתן דוגמה שהאמת היא הסיבה מדוע זה מומלץ : כאשר ה-PK מוגדר על מפתח שהוא בשימוש האפליקציה (מזהה ישות), תגיע בקלות למצב שהעמודה שמהווה את ה-PK מופיעה בהרבה טבלאות אחרות כ-FK (מאחר ולא מעט ישויות הינן ישויות המורכבות מטבלאות master/detail). מאחר ומזהה הישות הוא בעל משמעות אפליקטיבית, לא מן הנמנע שביום מן הימים יוחלט שיש לעדכן את מבנה המזהה, לדוגמה - אם המזהה הכיל את השנה בשתי ספרות ובגרסה החדשה מחליטים שזה יהיה 4 ספרות (כבר הפסקתי לספור כמה מערכות ראיתי שנתקלו בצורך). לעתים, השינוי של המפתח מצריך שינוי של כל המפתחות שקיימים כבר ב-DB, מה שאומר שעכשיו צריך לעבור על כל הטבלה ולעדכן את ה-PK של הטבלה הראשית (!!!) וכמובן שהמזהה הזה נמצא בשימוש בעוד עשרות טבלאות אחרות בתור FK (!!!) - בהצלחה בעדכון ! עכשיו דמיין דבר דומה כשהמפתח האפליקטיבי מורכב מכמה שדות, ופתאום מחליטים להוסיף עוד שדה למפתח האפליקטיבי - זה אומר שצריך להוסיף עוד מפתח בכל הטבלאות המקושרות !! דרך אגב, במקרה הנ"ל ניתקלתי בעבר במערכת GIS מאוד גדולה שהיה להם מפתח אפליקטיבי מרובה עמודות כ-PK וכשהם ניתקלו במצב שהם צריכים להוסיף עוד עמודה הם פחות או יותר בנו את כל ה-DB שלהם מחדש (עבודה של כמה חודשים).

 

[עידו פ]

עוד דוגמה "מהשטח"

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

 

[שוּלה]

../images/Emo45.gif והנה הצד השני של המטבע

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

), הסיבוכיות שאתה מוסיף לקוד שלך עם PK לא אפליקטיבי - פשוט לא משתלמת מבחינת זמן פיתוח, בגלל שכל גישה ל-DB מוסיפה עוד AND אחד לשאילתה, או ממש להכפיל את מס' השאילתות, למשל. במערכות גדולות הסיבוך של הקוד נשאר באותו סדר גודל, וב-99.9% מהמקרים הייתי נמנע מ-PK אפליקטיבי (מנסיון). ו...כן, הביצועים ייפגעו בעקיפין כתוצאה מכך, ובד"כ באופן זניח. אם אתה בכל זאת נאלץ לבחור PK אפליקטיבי, אל תניח הנחות לגבי השדה. למשל, אל תחסוך במקום (אל תתן רק 9 ספרות למס' זהות, או 2 ספרות לשנה כמו בדוגמה הנ"ל) כדי לתת מרחב לכל מני קריזות עתידיות להתרחש בלי שזה יפגע בשורת קוד או בחו"ח הגדרות DB. עוד דוגמאות לא להשתמש ב-PK אפליקטיבי, או במפתחות מרובי שדות - במצבים מצב בהם אחד ממרכיבי המפתח הם לא INTEGER, וזאת משיקולי ביצועים ו/או כפילות. (הצהרה מעורפלת ומטופשת, נכון, אבל היא מבוססת סטטיסטית על נסיון

)

 

[עידו פ]

לא הצלחתי להבין את הדוגמה

של מערכות קטנות : 1. שינוי PK אפליקטיבי הוא יותר חריף במערכות בהן יש ריבוי קשרים בין טבלאות, ולאו דווקא בטבלאות יותר "קטנות" מבחינת נפחים (גם אם יש 200 רשומות בטבלה הראשית, אבל יש לה נגררות ב-400 טבלאות, עדין שינוי ה-PK יהיה משמעותי) 2. היכן את רואה את הסיבוכיות בקוד בהוספת PK שאינו אפליקטיבי ? בסה"כ מדובר בעוד שדה שיש לשמור (מה עוד ששדה זה ניתן לו ערך פעם אחת ביצירת הישות ולאחר מכן הוא לא אמור להתעדכן). 3. מדוע לבצע תוספת של שאילתות ?! אם מחפשים לפי ה-PK, אין צורך לחפש לפי המפתח האפליקטיבי, אם מחפשים לפי המפתח האפליקטיבי, אין צורך לחפש לפי ה-PK (בהנחה והמפתח האפליקטיבי מאונדקס וחד-ערכי). במרבית המקרים אין "תוספת" של שאילתות אלא תיקון של השאילתות ע"י התייחסות לעמודה הרלוונטית. בכל מקרה הנקודה שאני מנסה להבהיר היא שבריבוי טבלאות וקשרים בין טבלאות, עדיף שה-PK שמשמש כמפתח ראשי לטבלה ולכן גם לקשרים שלה לטבלאות אחרות לא יהיה אפליקטיבי, זה הכל.