שאלת עיצוב

[danielthewhite]

שאלת עיצוב

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

 

[0 אור 0]

החלטות כאלו הן תלויות אפליקציה וסביבת עבודה

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

 

[danielthewhite]

זו בדיוק הנקודה...

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

השאלה היא מבחינת נורמליזציה של בסיס הנתונים - האם יש שיטה שהיא נכונה יותר עיצובית.

תודה!

 

[0 אור 0]

לא בטוח שיש

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

 

[danielthewhite]

יש חלק מהשדות

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

1. כן
2. לא

 

[pitoach]

לא מדוייק לדעתי

מערכת נכונה צריכה להיות גמישה ככל הניתן

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

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


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