לא רק שמתאים אלא לפעמים מאוד מומלץ
בעיקר במערכות גדולות (אני לא טוען שבמקרה הנוכחי זה נכון או לא ולא הצצתי בכלל בשום קוד או בשאלה המקורית עדיין). זה נקודה מאוד חשובה בארכיטקטורה של מסדי נתונים!
* יש מספר טבלאות עזר שתאורטית אפשר לטעון שאנחנו לא צריכים להחזיק מכיוון שהן לא מספקות נתונים חדשים (מספקים מידע מחושב). לדוגמה:
1. טבלת מספרים: טבלה פשוטה שמכילה רק מספרים מ 1 ועד כמה שיותר בהתאם למערכת (הכוונה למאות מליוני מספרים לפעמים) .
2. טבלת תאריכים: שוב מדובר ב"סתם" טבלה שמכילה את כל התאריכים ב 50 שנים האחרונות או בהתאם לכמה שצריך בהתאם למערכת.
ועוד...
* הערה: טבלת מספרים היא חובה בכל מערכת! בין השאר במערכות שאינן כוללות פעולות כבדות על תאריכים ספציפית אז טבלת המספרים יכולה לשמש במקום טבלת תאריכים (תאריך הוא בסך הכל מספר מאחורי הקלעים, אם עדיין לא ידעתם). למעשה זוהי אחת הנקודות שעוזרות לזהות ארכיטקטורה לקויה בכמה שניות, אם אני מגיע למערכת ורואה שהיא לא כוללת טבלת מספרים אני יודע שככל הנראה אפשר לשפר שאילתות.
הערה: שרת ה SQL כולל כבר בצורה מובנית טבלת מספרים בטבלאות המערכת, אבל היא כוללת כמות זניחה של מספרים שהתאימה לתקופה של גרסת SQL 2000 (כן כבר אז הבינו את היתרון בכך) ואין לה משמעות היום כמעט.
הערה: מספיק להחזיק טבלאות עזר במסד נתונים אחד משותף ואין שום הגיון בדרך כלל להחזיק אותם בכל מסד נתנים בנפרד (אלא אם יש מגבלות הרשאות למשל). באופן כללי אם אתם מנהלים את הסביבה שלכם אפשר להחזיק מסד נתונים כללי במצב read only שהוא מכיל פונקציות ופרוצדורות וטבלאות עזר ועוד, והוא נגיש לכולם לקריאה (זה מה שאני מחזיק בכל שרת בדרך כלל). יש לכך סיבות רבות...
למה צריך טבלאות עזר אלו ואחרות? נתונים אלו כאילו סתם יושבים בשרת ותופסים לנו מקום בדיסק, אחרי הכל ניתן לבנות את הנתונים בצורה דינמית כאשר צריך. אבל כאן מתחבא ה"כסף" הגדול (או המשאבים המבוזבזים).
הפורום אינו מקום מתאים להתחיל לפרט לעומק וישנם עשרות אלפי דוגמאות בפורומים ובבלוגים כיצד משפרים שאילתות בעזרת שימוש בטבלאות מספרים במאות אחוזים. מאוד מומלץ לחפש בגוגל משהו כמו: sql numbers table
נקודות חשובות נוספות!
* זמן מקומי תלוי אכן במיקום, אבל זמן ניתן לתרגם בפעולה זולה של חשבון (חיבור וחיסור הן מהפעולות הזולות ביותר במחשבים) לעומת לוגיקה מורכבת לפעמים. על אחת כמה וכמה כאשר החישוב כולל שילוב נתונים אחרים ממסד הנתונים. חישובים אלו בדרך כלל עדיף לבצע באפליקציה ולא בשרת הנתונים.
* טבלת עזר כללית של תאריכים או אם יש צורך טבלת זמנים לא בהכרח כוללת זמנים במיקום מסוים, אלא זמנים "ריקים", את החלק של ניתוח מבצעים בחישוב או בשילוב (JOIN) נתונים של טבלאות. עם זה טבלאות עזר ייעודיות למערכת מסוימת יכולות בהחלט להכיל רק זמנים או תאריכים מסוימים.
* (~)לעתים נכון להחזיק טבלת זמנים מלאה מקושרת לטבלה של אירועים (ולשלב דינמית נתונים). הכוונה לטבלת אירועים אחת שכוללת את כל סוגי האירועים כמו חגים, ימי הולדת, וכו' כאשר לכל אירוע יש רשומה אחת בלבד גם אם האירוע חוזר כמה פעמים. (~)לעתים נכון יותר להחזיק טבלת זמני אירועים שאינה כוללת את פרטי האירוע בכלל אלא רק הזמנים הספציפיים (ז"א אם האירוע חוזר על עצמו אז מדובר על אירוע חדש) ובטבלה מקושרת את הפירוט של האירוע (הפירוט יכול להיות משותף לכמה זמני אירוע). לעתים יותר נכון יהיה להחזיק טבלת זמנים הכוללת את כל הזמנים וכן באותה טבלה טור עבור כל סוג אירוע (למשל טור עבור סימון האם תאריך זה הוא חג או לא, טור עבור האם תאריך זה הוא שבת או לא וכן הלאה). (~)לעתים לא נכון להחזיק טבלת זמנים בכלל וצריך לחשב דינמית בשאילתה או בכלל באפליקציה עצמה, (~)ועוד... ישנם עשרות צורות שונות של ארכיטקטורה שיכולה להתאים לצרכים ספציפיים של המערכת.
* טבלאות עזר הכוללות מידע שניתן להגיע אליו הם כלי יעיל לשיפור ביצועים. הרבה פעמים אנחנו גם מחזיקים למשל טבלאות הכוללות ניתוח של טבלאות אחרות: למשל אם יש לנו לוג שבודק מאה אלף נתונים בשנייה ופעם בשבוע אנחנו צריכים להוציא סטטיסטיקות הכוללות מידע אחורה ומידע חדש, אז הרבה פעמים ארכיטקטורה נכונה תהיה להכין טבלת סיכום וכך נוכל בזמן הניתוח לבצע ניתוח רק של טבלת הסיכום + התכנים החדשים שעדיין אל סוכמו (וכמובן במקביל נעביר את הסיכום החדש לטבלת הסיכום).
