תכנון מסד נתונים

[dovid]

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

לגבי מחיר, ודאי ששומרים את המחיר יחד עם הקניה.

[מנצפך]

@dovid וודאי שאני שומר את המחיר הכללי, שאלתי היתה על שמירת המחיר של כל מוצר ומוצר.
תודה על תשובתך.

[dovid]

@מנצפך אכן ע"ז עניתי, על כל פריט קנוי יש שורה עם המזהה מוצר + מחיר אקטואלי.

[upsilon01]

@מנצפך

פתרון קצת יותר מסובך:
בטבלה של המוצרים תוסיף עמודה של version לדוגמא:

id | version | name | price  | size | enabled |
-----------------------------------------------
101| 01      | abc  | 100    |  15  |  false
101| 02      | def  | 150    |  30  |  true

כל פעם שיש עריכה של המוצר תשנה את enabled ל false
ותיצור רשומה חדשה עם version +1 ו enabled = true

ובטבלת הקניות תוסיף את הערך של version

כשתרצה להציג את רשימת המוצרים תסנן לפי הערך של enabled

[חבלזון]

@מנצפך אם השתנתה המהות - מדוע אתה קורא לזה "אותו מוצר"?
מדוע להשתמש באותו ID?
אם זה בשביל המחקר העתידי (מוצרים פופולריים), אפשר כמובן להוסיף "קטגוריה" וכדו'

[upsilon01]

@חבלזון
לדוגמא אם אתה מפתח מערכת לחנויות ובעל החנות עורך את פרטי המוצר
אז ה id נשאר אותו הדבר

[chagold]

גם אצל בעל החנות לא אמור להיות מוצרים משתנים. וכמו שאמרו כל מוצר יש לו את המהות שלו ואי"צ לגדיר מהות מוצר (לאותו ID) יותר מפעם אחת

[upsilon01]

@chagold
כשהמוצר הוא שירות אז הפרטים כן משתנים

[chagold]

@upsilon01 אמר בתכנון מסד נתונים:

@chagold
כשהמוצר הוא שירות אז הפרטים כן משתנים

צודק.
אבל נר"ל שא"כ עדיף לעשות טבלה נפרדת לversion's (וודאי שלא להחזיק באותה טבלה ID כפול).

[מנצפך]

@upsilon01 אמר בתכנון מסד נתונים:

בטבלה של המוצרים תוסיף עמודה של version לדוגמא:

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

[מנצפך]

המוצר הוא: זמן.
ולכן יכול להשתנות בין 30 דקות ל 35 דקות, נניח.
ואין זה מהות אחרת.

אני יכול לא לאפשר עריכת מוצר.
זו דווקא אפשרות שלא נראית לי הזויה בכלל.

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

[upsilon01]

@chagold לא הבנתי איך

[chagold]

@upsilon01 אמר בתכנון מסד נתונים:

@chagold לא הבנתי איך

(לא הבנתי מה כוונת @מנצפך על זמן, אז אני עונה רק על מה שכתבתי לפני כן)

לעשות טבלה שתעסוק בגרסאות מוצרים, ויהיה שם שדה ID של מוצר ועוד שדה של מס' גרסה. (ועוד מס' שדות לפי הנתונים הדינמיים).
ותמיד כשיגשו למוצרים יהיה אפשר להעלות את כל הגרסאות עם JOIN.
(ואפשר לעשות שבטבלת מוצרים יהיה ג"כ שדה של 'מס' גרסה נוכחית' דהיינו שיכיל id של השדה המתאים מטבלת הגרסאות (ולייבא אותם תמיד עם join), וכך יהיה אפשר להחזיק גרסה נוכחית של כל מוצר)

[clickone]

@מנצפך
תעשה מוצר שנקראת דקת עבודה (לפי חישוב יחסי)
ובכמות תשים לפי מספר הדקות.
בכלל, כמות + סכום ליחידה + סכום כולל (אם יש) חייב להישמר בDB בכל עסקה מחדש.
אף פעם אל תסמוך על הגדרות המוצר בזה.

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

[מנצפך]

@clickone אמר בתכנון מסד נתונים:

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

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

[clickone]

@מנצפך למה?
זה נחשב מוצר אחר
לדוגמא:

• דקת פיתוח = 3 ש"ח
• דקת תמיכה 1 ש"ח
• דקת שיחה 20 אג'

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

וזה לא מונע ממך לחשב כמה שעות היה בפועל לפיתוח, תמיכה וכו'

[upsilon01]

אבל נותן השרות מוכר חבילות של דקות במחיר משתנה

דקת פיתוח = 1 שח
15 דקות = 6 שח
שעה = 15 שח

[WWW]

@upsilon01 אז עושים הנחה.
כמו במכולת 3 ב 10

[upsilon01]

@www
ואז צריך להחזיק טבלה של הנחות

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