תכנון תיעדוף משימות

[mekev]

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

אני מעוניין לאפשר למנהל
לדרג כל בוקר מרשימת העבודות הפתוחות
את סדר העבודה (תיעדוף) לכל מחלקה בנפרד
(שזה אומר שאותה עבודה במחלקה x ממוקמת בעדיפות 1, ובמחלקה R ממוקמת בעדיפות 3)

ולהציג לעובד במחלקה
את רשימת העבודות במחלקתו לפי מיון רמת הדחיפות

איך ניגשים לתכנן/לבצע דבר כזה?

--
מסד נתונים sql server

[yossiz]

יש לי הצעה פשוטה, לא לשמור את זה כמידע טבלאי אלא כמערך (יש מערכים בsql server? אולי משהו דומה? JSON?)
מערך אחד לכל מחקלה, המערך יכיל רשימה של מזהי עבודות לפי סדר העדיפויות

[dovid]

אני חושב שהתכנון פה צריך שיפור.
העובדה ששורה בודדת של "עבודה" משמשת כמה מחלקות, צריכה להיות "כתובה" היכנשהוא.
ולכן אני מציע לעשות טבלה של מחלקה-עבודה, שתיראה ככה:
עבודה - מחלקה - עדיפות - מצב
עבודה - מחלקה - עדיפות - מצב
עבודה - מחלקה - עדיפות - מצב

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

[dovid]

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

[yossiz]

@dovid הבנתי מתוך השאלה שזה לא חלק מהותי של המודל, זה רשימה זמנית שהמנהל בוחר כל בוקר כמה עבודות מכל העבודות ומדרג אותם, הדירוג תקף רק ליום זה ולא קיימת עבור כל עבודה
@mekev תקן אותי אם טעיתי

[mekev]

@yossiz כתב בתכנון תיעדוף משימות:

הבנתי מתוך השאלה שזה לא חלק מהותי של המודל, זה רשימה זמנית שהמנהל בוחר כל בוקר כמה עבודות מכל העבודות ומדרג אותם, הדירוג תקף רק ליום זה ולא קיימת עבור כל עבודה

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

[יעקב2]

@mekev אתה אומר שזה מסד נתונים של SQL אבל הייתי עושה את זה מהתחלה עד הסוף באקסל פשוט
ע"י כמה גליונות
גיליון 1: טור רשימת כל העבודות בA טור מחלקה 1 בB מחלקה 2 בC וכן הלאה
כל מנהל נכנס בבוקר ומסמן בטור שלו את הסדר

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

[yossiz]

@יעקב2 אקסל הוא טוב ויפה עד שצריך לבנות ממשקים מסביב לו
זה לא רלוונטי כלל בנידון דידן

[dovid]

@יעקב2 כשתהיה מתכנת תבין למה זה לא רלוונטי.

[יעקב2]

@dovid @yossiz מקבל
השאלה האם הדרך שלי באקסל לא יכולה לעזור לו גם בתכנות (על אותו רעיון)
כי גם SQL זה טבלאות
אבל בהחלט אני לא מתכנת (כן לומד מפה ושם) ניסיתי לפתור לו את הבעיה הספציפית

[dovid]

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

[yossiz]

@יעקב2 להבין למה אקסל לא רלוונטי לא צריך להיות מתכנת רק להיות משתמש פשוט, @mekev מדבר על מערכת יותר גדולה עם ממשק יפה, החלק הזה הוא רק חלק קטן ממנו, אתה מבין לבד שלשתף קבצי אקסל כחלק מהמערכת השלימה זה לא לעניין

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

[dovid]

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

[mekev]

@dovid כתב בתכנון תיעדוף משימות:

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

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

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

[dovid]

@mekev הבנת את ההצעה שלי לעיל?
הטיעון בשוליות של התיעדוף היא טפל, כי גם אם הצורך שלך בתיעדוף חלף, עדיין אני עומד על דעתי שצריכה להיות הטבלה שמקשרת בין עבודה למחלקה ולא להסתמך על עמודות/מידע/קוד שרירותי.

[yossiz]

@dovid כתב בתכנון תיעדוף משימות:

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

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

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

[dovid]

@yossiz לא דיברנו על שני נושאים שונים, אתה התרכזת במיקרו ואני מסית אותך לראות את המאקרו.

לא ראיתי רמז בדברי @mekev שהמצב לא ככה כבר היום

א. הוא דיבר על טבלה אחת בלבד, טבלת עבודות.
ב. אם היה טבלה של קשר השאלה לא הייתה נולדת בכלל... היה טבעי לשים את זה שם בעמודה, מה זה עולה לו?
כל השאלה היא איך לחסוך לעשות עמודת תיעדוף פר מחלקה בטבלת העבודות, כלומר שטבלת העבודות תיראה רח"ל ככה:

ID | שם עבודה | בלה | בלה | תעידוף מחלקה X | תיעדוף מחלקה R | תיעדוף מחלקה Z

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