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

[יעקב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

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