Generic DB or Who needs DB?

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

בסיס נתונים כזה יכיל בדרך כלל טבלה בשם Entities או Entities_Types, אשר מכילה את הגדרת הישויות השונות, טבלה בשם Entity_Fields המכילה הגדרות של השדות השונים בכל ישות, וטבלה בשם Entity_Data, המכילה אוסף שדות, בדרך כלל מסוג String, המייצגים את נתוני הישויות עצמן. בנוסף נמצא בבסיס נתונים כזה בדרך כלל גם טבלה בשם Entity_Links המכילה את הקשרים בין הישויות השונות.

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

אז זהו שלא.

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

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

2. אין דרך לאכוף, ברמת בסיס הנתונים, את סוגי הנתונים הנשמרים. כל הנתונים מאוחסנים כ- String, ומבחינת בסיס הנתונים אין משמעות ל- Meta Data המוגדר.

3. לא ניתן לעשות שימוש בכלי DB מתקדמים יותר כגון Partitioning, משום שכל הנתונים נשמרים בטבלה אחת.

4. לא ניתן לעשות שימוש ב- Foreign Keys ו- Constraints, וממילא ה- Data Integrity, שהוא ליבו של בסיס הנתונים המודרני, נפגע קשות.

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

6. כלי ORM מודרניים כדוגמת Entity Framework, LINQ 2 SQL, NHibernate לא יודעים להתמודד בצורה טבעית עם בסיס נתונים שמתוכנן כך.

ואחרון חביב – המוטיבציה העיקרית לבניית בסיס נתונים בצורה זו היא, כאמור, היכולת להוסיף מהר סוגי ישויות חדשים, אולם הנסיון מראה שבדרך כלל עיקר הזמן בהוספת ישויות חדשות מתבזבז על סוגיות אפיוניות, התאמות ב- UI ושינויים ב- BL. אותן 3 שעות שבהן יבנה ה- DBA את הטבלאות החדשות אינן משמעותיות.

למעשה, משמעות העיצוב הנ”ל הינה ויתור מלא על יכולות ה- DB, ובניה של DB חליפי על גביו. ואם זה המצב – לא חבל להוציא כסף על בסיס נתונים מודרני? יש לנו File System מצוין שאפשר להשתמש בו! אמנם אין לו מפתחות, אינדקסים, בדיקות תקינות וכו’ – אבל מי צריך אותם?! אנחנו כבר נבנה את בסיס הנתונים שלנו לבד!

ואתם יודעים מה? אל תאמינו לי. אני מזמין אתכם לראות מה יש ל- Tom Kyte, Oracle VP להגיד בנושא. הוא אולי מתחרה של מיקרוסופט, אבל יש דברים שבהם הקונצנזוס חוצה גבולות וחברות. הקישור להלן מפנה למצגת שהוא העביר לפני כשנה בשם Oracle Database Worst Practices. שימו לב מה יש לו להגיד בשקפים 16-22. (גם השאר מעניין…)

http://www.ukocn.com/forums/database-dbms/dbms-technical-network/tom-kyte-oracle-database-worst-practices

אז לסיכום – אם כבר החלטתם לעשות שימוש בבסיס נתונים (ורוב הסיכויים שכך החלטתם…) עשו בו שימוש כמו בבסיס נתונים, ולא כמו ב- File System. אל תבנו טבלאות Meta Data – לבסיס הנתונים כבר יש כאלה משל עצמו, הוא לא צריך עוד.

זכרו – לא תמיד הפתרון הפשוט ביותר הוא המוטעה…