none
איפה לעזאזל שמתי את המפתחות (הראשיים) שלי? - עמי לוין, סיכום הרצאה RRS feed

  • דיון כללי

  • תודה לכל מי שהקדיש מזמנו ובא למפגש ואפילו נשאר מעבר לזמן המוקצב, על חשבון זמן איכות בערב :-)

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

    אתם יכולים להוריד את הקוד והמצגת כאן:

    https://github.com/ami-levin/Keys-Session/tree/master
    (הפורום לא נותן לי לשים Hyperlink ...)

    ניתן לצפות בהקלטה של האירוע בקישור הבא:
    http://youtu.be/XRKkaZ3x8kU

    אם יש לכם שאלות נוספות אשמח לענות כאן בפורום.

    2 שאלות שלא הספקנו להתייחס אליהן במהלך המפגש:

    שאלה:
    "יש לי התנגדות חזקה לשימוש ב CASCADE מכיוון שהוא ממומש ב SERIALIZABLE ISOLATION ו KEY RANGE LOCKS."
    תשובה:
    א. CASCADE ממומש ב SERIALIZABLE מכיוון שזו הדרך היחידה שהשרת יכול להבטיח את תקינות הנתונים במהלך ה CASCADE. תחשוב מה יקרה אם אתה עושה עדכון CASCADE ומישהו בדיוק מכניס שורה חדשה שגם נופלת בטווח שצריך לעדכן.

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

    ג. באופן טבעי, מפתחות טבעיים לא משתנים הרבה. תנסו לחשוב על מאפיין מזהה של ישות כלשהיא בעולם האמיתי שמשתנה אפילו פעם ביום או בשבוע... זה לא קורה כי אם זה היה קורה אז לא היינו משתמשים במאפיין כמזהה. :-)
    כפי שאמרתי והדגמתי עם המדינה ששינתה את שמה, למפתח טבעי יהיה מחיר כלשהוא לשלם כאשר המאפיין משתנה.
    לשמחתנו זה קורה לעיתים רחוקות מאוד.
    בסה"כ נראה לי עסקה לא רעה לשלם את המחיר של לעשות אפילו פי 1000 יותר עבודה לעדכון כזה פעם בשנה, אם כל שאר השאילתות שרצות מאות פעמים בשניה ייקחו 1/10 או 1/100 מהעבודה שהן צריכות לעשות בלעדיו, שלא לדבר על תקינות הנתונים...

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

    שאלה סופר חשובה: (הניסוח במקור)
    יש יוצאים מן הכלל? 

    תשובה פחות חשובה:

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

    רונן נתן דוגמא לא רעה של PostID בפורומים כמו כאן שאפשר לקחת גם לכיוון של מפתח טבעי וגם למלאכותי. המפתח הטבעי יהיה משהו כמו שם המשתמש + כותרת + זמן הפרסום. אם אורך המפתח יעבור את המגבלה של 900 בתים לאורך מפתח אינדקס לא תוכלו להשתמש בו ב SQL Server. גם למנועים אחרים יש מגבלות. 

    דוגמא נוספת יכולה להיות Event Log שבו ייתכנו אירועים זהים לחלוטין באותו הזמן, בתלות ברזולוציה של מאפיין הזמן שבחרתם. כאן אפשר להוסיף EventID ש"יעזור לנו לזהות", אבל יש גם פתרונות אחרים - למשל להוסיף טור Event Count ולקדם אותו אם יש ארוע כפול במקום 2 שורות. 
    ברוב המקרים משתמשים בו רק אם יש בעיה, ולכן פחות קריטי המבנה והתקינות אלא אם כן מדובר ביישום שתפקידו בחיים זה לנהל Event Logs, ואז סביר להניח שתרצו לפרק את המידע למבנה "מנורמל" עם טבלאות נפרדות לסוגי ארועים, מקורות וכולי. 
    אני טוען ש Event Logs שמאוחסנים בטבלה במסד רלציוני נמצאים שם ברוב המקרים רק מכיוון שלמפתחים היה נוח להשתמש כבר ב API והחיבור הקיים במקום לפתוח עוד חיבור ולערב עוד טכנולוגיה ואני בד"כ ממליץ לא לשמור Event Logs במסד הרלציוני - יש כלים טובים יותר שמיועדים לזה כמו Elastic ואחרים. גם מסדי NOSQL למיניהם יהיו פתרון מצויין ל Event Logs.

    אשמח לענות אם יש עוד שאלות, ואשמח גם ל Feedback על ההרצאה וההדגמות!

    שבוע מצויין לכולם!

    עמי 



    • נערך על-ידי AmiLevin יום רביעי 24 יולי 2019 15:50
    • פוצל על-ידי pituachMVP, Editor יום חמישי 25 יולי 2019 04:35 מתאים יותר כהודעה חדשה
    • נערך על-ידי pituachMVP, Editor יום שישי 26 יולי 2019 00:15 הוספת קישור לההקלטה
    יום רביעי 24 יולי 2019 15:47

כל התגובות