DB של הזמנות
-
לא ברור לי כ"כ הסיטואציה
כל מוקד מזמין בנפרד?
למה ההזמנה היא לא פר ספק? -
טבלאות:
ספקים
מוקדים
לקוחות
מוצרים (מכיל מזהה ספק)
הזמנות (מכיל גם מזהה לקוח, ומזהה מוקד)
פרטי הזמנה (מזהה הזמנה, מזהה מוצר)לשליפת כל המוצרים פר ספק פר מוקד,
אתה מחבר את ההזמנות עם הפרטי הזמנה, ומסנן/מקבץ לפי ספק ולפי מוקד.
בשביל לעשות כזה JOIN בsequelize תוכל לכתוב קודם SQL ואז לשאול פה (או בGPT?) איך כותבים זאת בsequelize. -
@meir-lamdan
את ההזמנה אני מקבל מהלקוח
היא מורכבת מכמה ספקים
ואני רוצה שכל ספק יקבל הזמנה אחת
שהיא מורכבת מכמה לקוחות -
@dovid כתב בDB של הזמנות:
טבלאות:
ספקים
מוקדים
לקוחות
מוצרים (מכיל מזהה ספק)
הזמנות (מכיל גם מזהה לקוח, ומזהה מוקד)
פרטי הזמנה (מזהה הזמנה, מזהה מוצר)לשליפת כל המוצרים פר ספק פר מוקד,
אתה מחבר את ההזמנות עם הפרטי הזמנה, ומסנן/מקבץ לפי ספק ולפי מוקד.
בשביל לעשות כזה JOIN בsequelize תוכל לכתוב קודם SQL ואז לשאול פה (או בGPT?) איך כותבים זאת בsequelize.לפי איך שזה נראה מדבריך החיבור בין הטבלאות הוא לא אמיתי אלא רק חזותי לפי שאילתא
וזה דופק לי את החלק של המחירים והחובות של כל מוקד
שאני רוצה שכל הזמנה יש את המחיר שלה וזה מתווסף לרשימת החובות של התחנה
וגם מאפשר לי לעשות שינויים לאחר זמן וכל המחירים שמורים בדאטה
אני צודק? -
@dovid אם אני יעשה הכל כשאילתות JOIN והמחיר יווצר בעזרת פונקציה, האם זה תקני
כלומר שבדאטה בעצם לא ישמר כלום
זה לא בעייתי?
שבמקרה של נפילת שרת אני מפסיד את כל הנתונים
לא עדיף שההזמנות והמחירים ישמרו בדאטה בצורה מסודרת שלא תוכל לגרום לשגיאות? -
@איש-פשוט-מאוד לפי התיאוריה האידאלית, אסור שבDATA זה יהיה כתוב בשום מקום, כי זה כפל נתונים (זה בבסיס חוקי הנרמול), כלומר כל שדה שניתן לחישוב אסור לשמירה. לכן הדרך שהצעתי היא בד"כ הדרך הטובה.
לעיתים כן בוחרים לשמור בטבלה נפרדת כזה ערך, או בגלל שיקולי ביצועים (למשל את יתרת החשבון בעו"ש יש מצב שלא רוצים לחשב כל פעם מיום פתיחת החשבון), או בגלל שיקולים שרירותיים של חילוט מצב, ששורת החוב תתנתק מכאן ואילך מהגורמים שחישבו אותה (שזה בדרך כלל זו החלטה שקשורה להתנהלות לא תקינה).
יש לציין שלהחלטה לשמור מידע כפול יש בעיות משמעותיות, זו לא סתם עבירה על המלצת ספרי הלימוד...לא הבנתי מה התכוונת במקרה שכתבת על נפילת שרת, המקרה הזה הוא דוקא עומד לטובת הימנעות משמירה כפולה, כי אם אתה שומר רק בטבלת הזמנות את המחיר אתה בפחות סיכון לאיבוד נתונים מאשר אם אתה מעתיק את הסכום למוקד לטבלה נפרדת, שאז יכול להיות כישלון חלקי ובעיית עקביות. טכנית יש לזה פתרונות, אבל ודאי שזה לא טיעון לטובת השמירה הכפולה.
-
@dovid כתב בDB של הזמנות:
לעיתים כן בוחרים לשמור בטבלה נפרדת כזה ערך, או בגלל שיקולי ביצועים (למשל את יתרת החשבון בעו"ש יש מצב שלא רוצים לחשב כל פעם מיום פתיחת החשבון
כתוספת:
כפי שראיתי בעבר במסדי נתונים של אי אלו תוכנות
הם שומרים גם את הסה"כ של המסמך בטבלת המסמך (בנידון דידן: עמודה עם ערך סה"כ הזמנה, בטבלת ההזמנות)
כך זה מאפשר להריץ דוחות על נתונים ללא צורך בתתי שאילתות
[ומאפשר לבדוק האם מישהו נגע בנתונים בטבלה המקושרת....] -
@dovid כתב בDB של הזמנות:
@איש-פשוט-מאוד לפי התיאוריה האידאלית, אסור שבDATA זה יהיה כתוב בשום מקום, כי זה כפל נתונים (זה בבסיס חוקי הנרמול), כלומר כל שדה שניתן לחישוב אסור לשמירה. לכן הדרך שהצעתי היא בד"כ הדרך הטובה.
זה אני יודע
מכאן נובע כל הקושי שלי
אחרת הייתי עושה פשוט טבלה שלימה נפרדת של הזמנות לספקים ולתחנות, ושולח פוסט בבת אחת לשתיהם@dovid כתב בDB של הזמנות:
לא הבנתי מה התכוונת במקרה שכתבת על נפילת שרת, המקרה הזה הוא דוקא עומד לטובת הימנעות משמירה כפולה, כי אם אתה שומר רק בטבלת הזמנות את המחיר אתה בפחות סיכון לאיבוד נתונים מאשר אם אתה מעתיק את הסכום למוקד לטבלה נפרדת, שאז יכול להיות כישלון חלקי ובעיית עקביות. טכנית יש לזה פתרונות, אבל ודאי שזה לא טיעון לטובת השמירה הכפולה.
עכשיו נפל לי האסימון למה אתה מתכוין
אני צריך טיפה לעבד בראש את הרעיון, אבל כבר יש לי כיוון
תודה רבה! -
@איש-פשוט-מאוד
@dovid
יש נקודה נוספת לדיון
וזה ערך המע"מ (לנוהגים.. כמובן...)במערכות תקניות נהוג לנהל את מחיר הפריט לפני מעמ
ויש לעיין האם לשמור את הנתון של ערך המעמ הנוכחי בטבלת הזמנות
מצד אחד זה נתון קבוע של תא בודד לפי טווח תאריכים
ולכן יש הגיון לשמור אותו פעם אחת בלבדמצד שני נוחות/קלות השליפה
במידה וזה מופיע כערך בשורת ההזמנה -
שמע"מ שומרים בטבלת הקבלות, שמה חייבים לחלט את הסכום וגם בגלל שזה טבלה אסורה לעדכון.
גם שמה אני רואה שנהוג לכתוב גם את הסכום לפני ואחרי וגם את ערך המעמ למרות שזה ניתן לחישוב כנראה לנוחות כאשר אמרת.
אני חושב שבטבלת הזמנות אפשר לחשב לפי ערכו של המע"מ (כקבוע או כערך משתנה).
אני לא הייתי שומר היסטורית את המע"מ כי אין לזה השלכה כל כך ברטרו, ומי שחוייב זה מופיע לו בקבלה.
