תכנון תיעדוף משימות
-
@yossiz בדברים שוליים אני מסכים שזה לגיטימי ווחוסך, אבל לא כשמדובר ממש במאפיינים מרכזיים/חזקים של המערכת.
במאפיינים של המערכת (שהם חלק ממש מהזרימה ולא איזה פרמטר שולי/זמני) פתרנות לא טבלאיים צריכים לבוא כאפשרות שניה לא בגלל יעילות אלא בגלל הבהירות של מה קורה במסד הנתונים וגם בגלל שבד"כ בהמשך רוצים להפעיל עליהם את כלל היכולות של מסד נתונים. -
@yossiz כתב בתכנון תיעדוף משימות:
הבנתי מתוך השאלה שזה לא חלק מהותי של המודל, זה רשימה זמנית שהמנהל בוחר כל בוקר כמה עבודות מכל העבודות ומדרג אותם, הדירוג תקף רק ליום זה ולא קיימת עבור כל עבודה
אכן
החלק של הדירוג
זה משהו זמני, שמשתנה כל הזמן
ואין לו משמעות מעבר לאפשרות מיון זמנית לפיו -
@mekev אתה אומר שזה מסד נתונים של SQL אבל הייתי עושה את זה מהתחלה עד הסוף באקסל פשוט
ע"י כמה גליונות
גיליון 1: טור רשימת כל העבודות בA טור מחלקה 1 בB מחלקה 2 בC וכן הלאה
כל מנהל נכנס בבוקר ומסמן בטור שלו את הסדרולכל מחלקה יהיה גיליון (שישותף לקריאה בלבד לעובדים במחלקה) שישאב את הנתונים ויסדר לפי סדר הדירוג במידה וקיים מספר בטור של המחלקה
מצטער אם גרמתי לזה לעבור מקטגוריית תכנות
-
-
-
@yossiz
אני סבור שזה כן מהותי, גם אם זה נתון שולי זמני וקטן, כי הנתון השולי הזה שייך למציאות מרכזית במערכת.
השורה של העבודה שייכת באמת לכמה מחלקות, זה לבטח משהו מרכזי בזרימת העבודה.
במקרה פה כעונים בפורום אין לנו מידע מה יש לתעד ומה יש לדעת מעבר לעדיפות בישות הזו של הקשר בין העבודה למחלקה, אבל אין ספק שיש. ישות עם מאפיינים שהיא חלק ממערכת ואין לה בכלל זכר בDB זה תכנון לקוי מבחינתי שעלול להוביל להרבה גישורים נוספים בסגנון. -
@יעקב2 להבין למה אקסל לא רלוונטי לא צריך להיות מתכנת רק להיות משתמש פשוט, @mekev מדבר על מערכת יותר גדולה עם ממשק יפה, החלק הזה הוא רק חלק קטן ממנו, אתה מבין לבד שלשתף קבצי אקסל כחלק מהמערכת השלימה זה לא לעניין
הדרך שלך דומה לשתי הדרכים שהוצעו למעלה. יותר דומה לדרך של @dovid אבל צריך להבין שיש הרבה יותר נתונים בדאטה בייס אז התכנון צריך להיות קצת יותר במחשבה תחילה מאשר בקבצי אקסל
-
@yossiz אם מתרגמים את מה ש@יעקב2 אמר לSQL מקבלים עמודה לכל מחלקה בטבלת העבודות, שזה לא היה עולה על דעתי.
זה אומר שאם רוצים להוריד/להוסיף מחלקה צריך שינוי בעיצוב הDB, וגם מפסידים אז היסטוריה (לא יודעים שהיה או לא היה המחלקה הזו וכדומה)
אבל המצב כעת כנראה גרוע יותר, שהרי אם תתן דעתך איך הקשר כיום בין העבודה למחלקות ביישום של השואל, תגיע למסקנה שזה סוג של קוד שרירותי ברמת האפליקציה. -
@dovid כתב בתכנון תיעדוף משימות:
אני סבור שזה כן מהותי, גם אם זה נתון שולי זמני וקטן, כי הנתון השולי הזה שייך למציאות מרכזית במערכת.
השורה של העבודה שייכת באמת לכמה מחלקות, זה לבטח משהו מרכזי בזרימת העבודה.
במקרה פה כעונים בפורום אין לנו מידע מה יש לתעד ומה יש לדעת מעבר לעדיפות בישות הזו של הקשר בין העבודה למחלקה, אבל אין ספק שיש. ישות עם מאפיינים שהיא חלק ממערכת ואין לה בכלל זכר בDB זה תכנון לקוי מבחינתי שעלול להוביל להרבה גישורים נוספים בסגנון.אם אקצין את דבריך
האם יהיה נכון להוסיף בטבלה
עמודה 'תיעדוף' פר מחלקה שמכילה את רמת התיעדוף הזמנית כרגע
למרות שזה מידע זמני, משתנה, ושאין לו שום משמעות מבחינת הדאטהבעוד הצורך הוא רק לאפשר למשתמש אחד לבצע סדר/מיון מסוים
ולשמור את התוצאה כתצוגה למשתמשים נוספים -
@dovid כתב בתכנון תיעדוף משימות:
שהרי אם תתן דעתך איך הקשר כיום בין העבודה למחלקות ביישום של השואל, תגיע למסקנה שזה סוג של קוד שרירותי ברמת האפליקציה
כנראה שדיברנו על שני נושאים שונים. ברור שהקישור בין עבודה למחלקה אמור להיות בטבלה מקשרת וכל מטה דאטה מסביב לשיוך הזה צריך להיות בטבלה המקשרת.
לא ראיתי רמז בדברי @mekev שהמצב לא ככה כבר היוםאני רק טענתי שהמידע הספציפי הזה של סדר העדיפיות של המשימות להיום הוא סתם פיסת מידע שעומד בפני עצמו וזה שייך לסדר היום של המחלקה ולא למשימה עצמה או לשיוך המשימה למחלקה
-
@yossiz לא דיברנו על שני נושאים שונים, אתה התרכזת במיקרו ואני מסית אותך לראות את המאקרו.
לא ראיתי רמז בדברי @mekev שהמצב לא ככה כבר היום
א. הוא דיבר על טבלה אחת בלבד, טבלת עבודות.
ב. אם היה טבלה של קשר השאלה לא הייתה נולדת בכלל... היה טבעי לשים את זה שם בעמודה, מה זה עולה לו?
כל השאלה היא איך לחסוך לעשות עמודת תיעדוף פר מחלקה בטבלת העבודות, כלומר שטבלת העבודות תיראה רח"ל ככה:ID | שם עבודה | בלה | בלה | תעידוף מחלקה X | תיעדוף מחלקה R | תיעדוף מחלקה Z
וזה השואל ממש לא רצה ולכן הוא בא לפה להציל מהדבר הזה (עד לפה אתה מסכים?).
ואז אמרתי לו, שיש לו בעיות מעבר לשאלה הנקודתית איפה "לדחוף" את התיעדוף.
