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

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

1. מחקו טבלאות ועמודות ישנות

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

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

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

2. בחרו שמות בעלי משמעות לעמודות

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

ממילא יהיו לנו פונקציות לעבודה עם בסיס הנתונים ואין בעיה בקוד לעשות את ההמרה אוטומטית (לדוגמה לכתוב price ולקבל עדכון של עמודת price_in_agorot). מאותה סיבה גם לא הייתי בוחר היום עמודה כמו start_dt או minprice. שמות מלאים וארוכים יעשו למערכת שלכם רק טוב.

3. שימרו על אחידות

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

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

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

יש לכם טיפים נוספים איך לשמור על בסיסי נתונים נקיים? ספרו לי בתגובות.