התייעצות: טבלת MetaData מול הרחבת הטבלה הקיימת
-
אני מפתח ללקוח שלי מערכת, שבה לכל משתמש יכול להיות אנשי קשר.
לכל איש קשר יש את הפרטים הקלאסיים, שם, משפחה וכו'
ויש פרטים שרלוונטיים לכל משתמש. לדוגמא: מספר נעליים (לא בצחוק. ברצינות. זו מערכת לעמותות)הדרישה היא שכל משתמש בתוכנה יוכל לבנות לעצמו שדות.
אני מתלבט בין 2 תצורות:- להוסיף בטבלה X שדות, ולתת למשתמש לשלוט על הכותרות.
כמובן שמחכה לי טיפול בסוגי הנתונים
- לעשות טבלת MetaData עם הגדרת שדות לכל לקוח, ומשם למשוך לכל איש קשר, ולתצוגת הטבלה.
גם שם אצטרך להתמודד עם סוג הנתונים.
שם יש לי 2 דרכים:
- הכל יישמר כטקסט ואני יעשה את ההמרה לפי העניין. (נשמע לי לא יעיל בכלל וקצת מטופש)
- לעשות 4 עמודות ערך, תאריך, מספר, טקסט, בוליאן ולשמור בעמודה לפי העניין. (גם נשמע מטופש, אבל פחות מבחינת השמירה, שהרי עמודה שיש בה NULL בקושי תופסת מקום [ככה בעבר יצא לנו כאן בדיון עם הארכי @ארכיטקט ])
כמובן שיהיה לי להתמודד עם נושא השליפה של הנתונים. בעיקר בתצוגת טבלה כללית (בעריכת איש קשר זה הרבה יותר פשוט)
יש עוד דרך שלא כתבתי, וזה לעשות שדה JSON, שבו יישמרו כל הפרופרטיז, זה נראה לי לא יעיל בכלל, בעיקר בגלל המשיכה והסינון.
קוד: C#
דאטאבייס: SqlServer
ממשק: Mvc + AngularJsתודה לכל מי שיש לו מחשבה מה הוא היה עושה
אל תהססו להציע דברים אחרים משלכם - להוסיף בטבלה X שדות, ולתת למשתמש לשלוט על הכותרות.
-
@clickone אמר בהתייעצות: טבלת MetaData מול הרחבת הטבלה הקיימת:
אל תהססו להציע דברים אחרים משלכם
להחליף מסד נתונים למסד כמו mongoDB, בדיוק בשביל זה נועדו המסדים האלה...
-
@יוסף-בן-שמעון
אממממ
רעיון
אני דיי בטוח שיש לזה מקבילה טובה בSQL SERVER
בכל מקרה, השאלה אם מונגו טוב לי לשאר הדברים
וגם אל תשכח, שזה פרוייקט שנמצא כבר באמצע דרכו. א"א פתאם באמצע העולם להחליף
מה גם, שEF לא יתמוך בזה.
ואין סיבה לסבול בכל הפרוייקט בלי EF בשביל הפיצ'ר הזה.... -
אני בעד שבטבלה הראשית אין שום מאפיין גמיש מבחינת קיומו מהותו וכותרתו.
אני בעד טבלה חיצונית, והאפשרות של טקסט היא לא כזאת טפשית.
ראה את המאמר הזה בויקיפדיה: https://en.wikipedia.org/wiki/Entity–attribute–value_model
הרעיון הוא לשמור ככה: מזהה לקוח, מזהה תוכנה, ערך מופרד באיזשהוא מפריד.
אבל הEAV הוא לפעמים קיצוני יותר, כשיש כמה סוגי ישויות, ויש תכונות עם כמה ערכים, ואז הכל זה שדה טקסט מופרד במפריד כל שהוא או JSON/XML. אגב בוורפרס יש כמה טבלאות בודדות וכל שאר הפרטים נשמרים בטבלה אחת בשיטה של EAV. השליפה לא יקרה כי זה מאונדקס כמחרוזת ומחפשים תמיד ע"י לייק של "מתחיל ב" - זה מהיר כמו אינדקס רגיל.הנה דיון על זה בsoftware-engine:
https://softwareengineering.stackexchange.com/q/93124/112215והנה שאלתך בסטאק: https://stackoverflow.com/q/870808/1271037
בתשובה שהתקבלה הוא מסכם את האפשרויות עם מעלותיהם וחסרונותיהם. -
אני מתחיל לאט לאט לשים כאן לינקים ודברים שיוצאים לי תוך כדי חקירת הנושא
- האם כדאי לבנות לבד או ללכת על משהו מוכן שכבר כתוב?
דוגמא:
https://www.nrecosite.com/semantic_storage_net.aspx
- האם כדאי לבנות לבד או ללכת על משהו מוכן שכבר כתוב?
-
-
@dovid זה מה שעשיתי
ועוד טבלה של הגדרת מאפיינים
להבנתי ככה הכי נכון לממש EAV בDB יחסי. (ז"א, לא אני המצאתי את הגלגל באיך לממש )
זה עובד מצויין ברמת המסך עריכת האיש קשר
כעת אני מתמודד עם הבעיות להביא את זה לטבלה של כל השמות (איטיות בעיקר)
מקווה בימים הקרובים להעלות לכאן חלק מהקוד -
@clickone אמר בהתייעצות: טבלת MetaData מול הרחבת הטבלה הקיימת:
ועוד טבלה של הגדרת מאפיינים
פה כבר עשית כמו ארכיטקט...
כעת אני מתמודד עם הבעיות להביא את זה לטבלה של כל השמות (איטיות בעיקר)
אני זוכר שעם ארכיטקט אכלנו קש בנידון (בשלב כל שהוא זה היה בשימוש בפקד של טלריק, הנה זכר לעניין: א, ב).
-
@dovid אמר בהתייעצות: טבלת MetaData מול הרחבת הטבלה הקיימת:
טבלה נוספת עם שדות של מזהה מאפיין וערך וזהו.
@dovid אמר בהתייעצות: טבלת MetaData מול הרחבת הטבלה הקיימת:
ועוד טבלה של הגדרת מאפיינים
פה כבר עשית כמו ארכיטקט...
טוב... התבלבלתי לגמרי
מה עוזר המזהה מאפיין אם אין לו טבלה שבה נמצאים המזהים הראשיים?
או שפיספסתי בהצעה שלך משהו -
@dovid למה בעצם לא להשתמש בPivot?
דוגמא:contacts.Pivot(X => X.Phones, X => X.PhoneType, X => string.Concat("(", X.AreaCode, ") ", X.PhoneNumber), true)https://stackoverflow.com/questions/8082057/how-to-use-pivot-table-with-entity-framework
http://linqlib.codeplex.com/wikipage?title=Pivot&referringTitle=Home -
), אבל מה ש@clickone הביא זה ברמת הקוד, כלומר הוא מתשאל רגיל ומסדר את זה אח"כ, אני חושב זה סתם קומבינה חמודה, ולא מתורגם לSQL.