ארגון מסד נתונים לניהול מנויים חודשיים
-
אשמח להמלצתכם
אני בונה מערכת לניהול מנויים לחוגים.
יש הורים ולהם ילדים כלומר יתכן משלם אחד על 2 ילדים
עכשיו המנוי הוא חודשי אבל אפשר כמובן לשלם מראש קדימה.
איך אני מארגן את זה.-
לכל ילד שירשם אצור 12 פריטים לכל חודש עתידי, וכאשר ישולם כמה חודשים אציין את אותם פריטים כשולמו, ואם עבר המועד כך אדע כמה זה כבר חוב, וכמה זה חוב עתידי. היתרון לכאורה בדרך הזו שיש לי גמישות מקסימלית של עצירה באמצע הורדת חודשים, שיוני מחיר לחודש ספציפי וכו' החסרון לכאו' אם יהיו אלפי תלמידים יהיו רבבות פריטים והכבדה על התפעול.
-
לבנות 12 פריטים לחודשי השנה וכל מי שמשלם עבור כל חודש כותב אותו בחודש הזה, למשל מי ששילם 3 חודשים מכניס אותו ב3 החודשים הבאים, וזה שהוא לא נמצא ב9 חודשים הבאים אני יודע שלא שילם, את המחיר אצטרך לקבוע ולהתאים בכרטיס הילד, ואז להכניס אותו לחודשים.
-
לשמור בכל תלמיד תאריך אחרון ששולם למשל מי ששילם לשנה שלמה, התאריך שלו יהיה כיום בעוד שנה, ואז אני יודע שהוא הכל משולם, אם רק 3 חודשים אז אשנה את השדה התאריך לעוד 3 חודשים.
איזו דרך הכי נכונה? בסופו של דבר אצטרך לעקוב אחר כל הורה אם יש לו חוב ואז להתריע וכו' ולאפשר תשלום עתידי ושינויי סכום לכל הורה, אולי גם אפשרות הפסקה באמצע, אני רוצה לקחת את כל זה בחשבון שהשאילתות יהיו פשוטות וביצוע המשימות כנ"ל.
אני יודע שלא פירטתי בכל אופציה חסרונות ויתרונות, בעיקר כי אני בטוח שאני לא חשבתי על כל הצדדים, ואשמח לשמוע ממכם.
תודה רבה. -
-
לא לגמרי הבנתי את 2 האפשרויות שלך.
אני אישית הייתי עושה טבלת תשלומים, עם מזהה משלם, תאריך תשלום, סכום.
על כל תשלום שמתבצע בפועל אני מוסיף שורה אחת בלבד. אם הוא שילם על חודש אחד, הסכום יהיה של חודש אחד. אם הוא שילם על שנה שלמה, הסכום יהיה של שנה שלמה.
אחכ אתה בכל רגע נתון יכול לחשב כמה חודשים התלמיד כבר בחוג (לפי הזמן שעבר מתאריך ההתחלה) * הסכום לתשלום לחודש וזה החוב שלו, ומהחוב אתה מוריד את הסכום ששולם, וכך אתה יכול לדעת האם הוא חייב לך כסף או ביתרת זכות. -
מצטרף לדברי @avr416.
אוסיף כמה מילים (שייתכן שהינם שגויים לגמרי כי אני מערער פה קצת על המציאות ובעצם אתה יודע יותר ממני מה המציאות בפועל שעבורה הזמינו את המערכת).
התפיסה שהתשלום הוא בכל חודש, היא להשערתי חוטאת קצת למציאות וגם אם לא, היא מגבילה למציאות הזו בלבד.
לטעמי לחוג יש מחיר אחד ופשוט גם אם את התשלום ניתן לפרוס, וגם ניתן להזכות על פרישה (כך נראה מהמקרה שלך), וגם אם גביית החוב הנותר היא ביחס לזמן שעבר מתחילת החוג.
כפי שאמר @avr416 הכי טבעי זה טבלת תשלומים, הרבה אנשים משלמים בבת אחת ויש כאלה שבמקום לשלם במשך כל חודשי החוג ישלמו רק בשלושת החודשים הראשונים את כלל הסכום.
שנית, מאותה סיבה אני סבור שלא אמורים לחשבן כמה תלמיד חייב. כל תלמיד חייב את כלל הסכום של החוג אליו הוא משוייך. במקרה של פרישה לפני הסוף ניתן ליצור שורת זיכוי בתשלומים (כלומר תשלום פיקטיבי), עם תיאור תשלום "זיכוי בגין פרישה". ככה יש לך שליטה האם בכלל לזכות וכמה, כי מחר יכול להיות חוג שיקבע כללי הזדכות של 80% לפורשים.
גם אם יש זיכוי למצטרפים מאוחרים, ניתן לפעול באותה דרך ולא לשעבד את המערכת למחשבה שתהשלום הוא פר חודש.למרות שאני טוען שמחיר החוג הוא לא באמת על חודשים אלא גלובלי, ברור שיש התייחסות למס' המפגשים, וגם אפשר להבין שמציקים לבן אדם על חוב לחוג רק כשמגיעים החודשים שהתשלום היחסי לא מכסה.
ולכן מתבקש שהתוכנה כן "תבין" את התקופתיות של החוג ואת המחיר בערך לכל מפגש.
לעניין זה לדעתי אפשר לעבוד בצורה גסה, המערכת תדע רק את תקופת החוג כלומר תאריך התחלה וסיום. בחישוב חובות ייעשה חלוקה של הסכום לחודשים שבין התאריכים, ואז כמה חוב יש בעבר לעומת כמה התלמיד חייב.
כל זה על הצד שאין למערכת נתונים על תאריכי המפגשים, כי אם גם זה אמור להיות מוזן למערכת אז זה יכול להיות מדוייק בהרבה (כי יכול להיות חוג בו החודשים בכלל לא הפקטור אלא המפגשים). במקרה כזה אני מתאר לעצמי שיש טבלת תאריכי מפגשים לכלל החוגים, ואז השאילתה היא מס' מפגשים שקטנים מהתאריך הנוכחי * (סכום לחוג / מס' מפגשים כולל)).לעניין החובות, הדרך הפשוטה זה עצם הישות שמקשרת בין תלמיד לחוג, שמה יהיה סכום וזה ייצור חוב. דרך אחרת שמאפשרת גמישות יותר זה ליצור שורת חיוב בתשלומים (תשלום מינוס) או טבלה ייעודית לחובות.
עוד:
א. השיקול של האפיון לא אמור להתרגש מיותר או פחות שורות, כמות שורות לא אמורה להכביד על מסד נתונים, אלא אם כן מדובר בפי אלפים.
ב. בד"כ באפיון נכון ככל האפשר של המציאות, והמרתה באופן הכי מתאים למסד נתונים, ממילא נהיה קל לעשות שאילתות. זה לא תמיד ככה, אבל זה ברוב המקרים.
גם להיפך, בניית מסד נתונים עם הטיה לנוחות התשאול על חשבון תיאור המציאות, עלול לסבול בשאילתות אחרת פשוטות. -
-
@אבי-203 כתב בארגון מסד נתונים לניהול מנויים חודשיים:
GPT 4 נתן לי להחליט בהתאם לחסרונות ויתרונות... למשל המליץ יותר על 1 אם אין הרבה תלמידים.
הוא פשוט זורם עם ההנחיות וההנחות שהנחת לו.
כתבת לו שיש בזה חיסרון כי אם יהיו תלמידים רבים אז יהיה רבבות שורות (כל אחד כפול חודשי החוג שלו), וזה מבחינתו נתון שלימדו אותו הרגע... מה גם שיש תרחישים שזה נכון, למשל במערכת משובצת מחשב...
