האם שדות ריקות בטבלה תופסות מקום בזיכרון?

[אבי]

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

תודה

פורסם במקור בפורום CODE613 ב19/09/2016 23:44 (+03:00)

[dovid]

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

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

פורסם במקור בפורום CODE613 ב20/09/2016 01:12 (+03:00)

[ארכיטקט]

@דוד ל.ט.

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

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

פורסם במקור בפורום CODE613 ב20/09/2016 05:57 (+03:00)

[רחמים]

@אבי

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

תודה

כשאתה מחלק טבלה לשתיים אתה לא חוסך מקום אלא אדרבא מוסיף 2 עמודות: עמודת מפתח זר לטבלת האב ועמודת מפתח ראשי לטבלת הילד.

פורסם במקור בפורום CODE613 ב25/09/2016 16:51 (+03:00)

[dovid]

@רחמים

כשאתה מחלק טבלה לשתיים אתה לא חוסך מקום אלא אדרבא מוסיף 2 עמודות: עמודת מפתח זר לטבלת האב ועמודת מפתח ראשי לטבלת הילד.

אם כל השורות היו מכילות כל אחת נתון בטבלה זרה, אכן התבזבזו 64 ביט נוספים לכל שורה.
אבל מכיון שישנם שורות שבהם תהיה רק שורה בטבלת האב עם 32 ביט ריק, ושורת הבן בכלל לא תיכתב אז נחסך מקום. אם למשל הערך הנידון מורכב משדה טקסטואלי באורך 50, ובהנחה שאקסס שומר טקסט ב8 ביט (מסתבר שיותר כי הרי זה מרובה שפות) זה יוצא 8*50=400. בשביל שיהיה כדאי פיצול די בכך שיהיו 15 אחוז שורות ריקות. זה כמובן תיאורטי מכמה סיבות, אבל זה הכיוון.

פורסם במקור בפורום CODE613 ב25/09/2016 21:00 (+03:00)

[רחמים]

@דוד ל.ט.

אם כל השורות היו מכילות כל אחת נתון בטבלה זרה, אכן התבזבזו 64 ביט נוספים לכל שורה.
אבל מכיון שישנם שורות שבהם תהיה רק שורה בטבלת האב עם 32 ביט ריק, ושורת הבן בכלל לא תיכתב אז נחסך מקום. אם למשל הערך הנידון מורכב משדה טקסטואלי באורך 50, ובהנחה שאקסס שומר טקסט ב8 ביט (מסתבר שיותר כי הרי זה מרובה שפות) זה יוצא 8*50=400. בשביל שיהיה כדאי פיצול די בכך שיהיו 15 אחוז שורות ריקות. זה כמובן תיאורטי מכמה סיבות, אבל זה הכיוון.

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

פורסם במקור בפורום CODE613 ב25/09/2016 21:38 (+03:00)

[dovid]

@רחמים

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

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

פורסם במקור בפורום CODE613 ב25/09/2016 22:54 (+03:00)

[dovid]

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

פורסם במקור בפורום CODE613 ב26/09/2016 08:57 (+03:00)

[רחמים]

@דוד ל.ט.

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

מה הכוונה ערכים חוזרים? ערך של שדה בודד שחוזר על עצמו בכמה רשומות חוסך משהו?

פורסם במקור בפורום CODE613 ב26/09/2016 18:33 (+03:00)

[dovid]

@רחמים

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

מה הכוונה ערכים חוזרים? ערך של שדה בודד שחוזר על עצמו בכמה רשומות חוסך משהו?

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

פורסם במקור בפורום CODE613 ב26/09/2016 19:08 (+03:00)

[רחמים]

@דוד ל.ט.

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

השאלה הייתה על שדות עם ערך NULL, אז הטענה הזו לא רלונטית.

פורסם במקור בפורום CODE613 ב27/09/2016 21:24 (+03:00)

[dovid]

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

פורסם במקור בפורום CODE613 ב29/09/2016 22:29 (+03:00)