asp.net mvc - ממשק טיפול בנתונים מקוננים

[zag78]

asp.net mvc - ממשק טיפול בנתונים מקוננים

שלום רב.

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

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

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

מה הדרך הפשוטה והיעילה לעיצוב UI מתאים?

בתודה מראש.

 

[דוד גילי]

הסברת כל כך יפה

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

 

[zag78]

הDB כבר נבנה

קיבלתי את הDB כנתון, ולכן אני צריך לבנות UI מתאים שיכניס, יעדכן ויציג נתונים.

 

[nocgod]

אולי אני מפספס משהו

אולי DBים השתנו מהפעם האחרונה שראיתי אחד...לפני שבוע...
ממתי אי אפשר לעשות יחסי many-to-many או single-to-many בDB באמצעות f-keys?

 

[דוד גילי]

אכן אתה מפספס.

מה שאתה מפספס (וגם אני שנים רבות פיספסתי), זה שיש הרבה מקרים שבהם פתרון של document הוא הרבה יותר הגיוני, וקל למימוש, ומהיר שאתה פשוט לא מאמין.
במערכת שלי יש משתמשים. רק חלק מהם הם מורים. וכל מה שקשור למורה הוא json שיושב בתוך ה json של המשתמש. יכולים להיות לו מקצועות שהוא מלמד זה שדה שמכיל מערך של סטרינגים. יש לו כרטיסי אשראי שהם... שוב אותו דבר. יש לו מיקומים גיאוגרפיים. אם הייתי פותח טבלה ועושה קישורים עם forneign key לכל אחד כזה, הייתי גומר בעוד שנתיים.
לפני 15 שנים היו בערך 3 דטהבייסים. אורקל שעלה מיליונים, sql server, ועוד איזה משהו בשוליים. היום יש יותר מ 150. כל מה שאני אומר זה: פתחו את העיניים.

 

[nocgod]

אתה מפספס פה משהו...

אתה מניח שאני לא מכיר או לא עבדתי עם בסיסי נתונים שהם noSQL, אני מסיק את זה מהדברים שכתבת. אתה כמובן טועה, אני עובד עם בסיסי נתונים לא SQLים ביום-יום ביניהם MongoDB ו Redis.
אתה צודק - יש מידע שהייצוג שלו הרבה יותר נוח וחשוף לקורא בdocument DBs למיניהם.
אני טוען שרוב המידע ניתן למידול איכותי כך שיהיה ניתן לשמור אותו ב DB רלציוני בצורה טובה. מה גם f-keys לא קללה, ואפשר להשתמש בהם כדי להביא את כל המידע שאתה רוצה ולחבר ביניהם.

בכל מקרה השאלה הייתה איך לייצג ב UI ולא ב DB.

 

[דוד גילי]

אין בעיה, הכל ברוח טובה.

אני עוד בהלם הגילוי של עולם ה nosql .

 

[nocgod]

הכי חשוב כשמגלים כלים חדשים לדעת להשליך אותם על בעיות נכונות

כי מה לעשות, לא כל מברג מתאים לבורג.

 

[MoAtlow]

אני איתך. כל כךהרבה יותר פשוט ונוח

 

[ziv1f]

כמובן אין בעיה עם רלציוני, אבל זה באמת מקרה קלאסי ל-docDB

במקרה שמחפשים או מדבגים נתונים של משפחה, אז במקרה שעושים את זה רלציוני זה או שאילתה עם 10 טבלאות, או 10 שאילתות שונות כל אחת מטבלה אחרת ועם הנתונים מהשאילתה הקודמת, ובמקרה שעובדים עם מונגו (למשל) אז זה שאילתה אחת ועם הכלי המתאים (מונגו-שף למשל, ממליץ בחום) זה פשוט להסתכל על הכל שמונח לפניך ולא צריך לחפור בתור ההיררכיה הרלציונית

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

וכמובן אם יש צורך מיוחד, אין שום מניעה להשתמש גם בזה וגם בזה וגם ב-key-value-store כמו רדיס, לדברים שצריך בשבילם מהירות ופשטות

בברכה,
זיו