SQL | ערכים מרובים בעמודה

[איש נחמד]

@www אמר בSQL | ערכים מרובים בעמודה:

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

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

[WWW]

@איש-נחמד אמר בSQL | ערכים מרובים בעמודה:

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

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

[איש נחמד]

יש כאן תגובה ארוכה שמסבירה למה יצירת טבלאות מרובות עדיפה (אם כי מובאות שם דעות נוספות) :
https://stackoverflow.com/a/3070426/11675758

[chagold]

@www https://saveriomiroddi.github.io/Storage-and-indexed-access-of-denormalized-columns-arrays-on-mysql-8.0-via-multi-valued-indexes/

עריכה: שו"ר ש@איש-נחמד הביא כעי"ז.

[dovid]

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

[WWW]

@dovid
OK.
JSON לא בא בחשבון?

במקרה האמיתי, מדובר בעוד כמה עמודות שהם מרובי ערכים, לדוגמה:

מזהה	שם	ימי עבודה	משמרות	מקצועות	שפות
1	אבי	1,2,3,5	1	1,2	עברית
2	יוני	1,2,3,4,5,6	1,2	2	עברית, אנגלית
3	משה	1,2,4,5	2	2,3	עברית, אנגלית, צרפתית

ועוד...
זה מאד מסבך ליצור עוד 10 טבלאות...

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

שאלה נוספת, זה גם מה שהיית עושה במקרה של המשמרות? כשאני יודע שיש רק 2 משמרות, ובעצם יש 3 מצבים: 1, 2, 1+2. לא היית שומר BIT באורך 1 עם 3 ערכים אפשריים: 0/1/2?
או לחילופין: 2 עמודות בינאריות: משמרת ראשונה, משמרת שנייה. רק שכאן אסור להיות בשניהם 0, (או שניהם 1 או אחד מהם 1)?

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

[dovid]

@www מצטער, לא הבנתי מה ההבדל בין המקרה האמיתי למה שחשבתי.
אני גם לא מבין מה הסתירה בין ימי עבודה 8 ל3 משמרות, תסביר לי טוב את המושגים או שבחר אחרים שקלים יותר להבנה, אשמח מאוד לשמוע סיפור מלא (הוא לא חייב להיות האמיתי אבל הוא חייב לייצג את כל הבעיות שיש באמיתי).
JSON לא נתמך בMYSQL לאינדוקס ותשאול מהירים ונרומלים.
בקשר לפלטפורמה, שים לב שכל המידע בעולם כמעט נכתב במסדי נתונים יחסיים ודי קשה להאמין שאתה חריג. ברור שיש מקרים שבמסדי נתונים אחרים החיים פשוטים יותר, אבל כדאי להחליט את זה אחרי שמכירים את החלופה על בוריה.

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

[WWW]

@dovid אמר בSQL | ערכים מרובים בעמודה:

@www מצטער, לא הבנתי מה ההבדל בין המקרה האמיתי למה שחשבתי.

אין כמעט הבדל, המקרים כמעט זהים.. אלא שיש עוד כמה עמודות כאלה, מה שהתכוונתי שלא מדובר בעוד 3 טבלאות, אלא בעוד 10...

@dovid אמר בSQL | ערכים מרובים בעמודה:

אני גם לא מבין מה הסתירה בין ימי עבודה 8 ל3 משמרות,

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

[WWW]

@dovid אמר בSQL | ערכים מרובים בעמודה:

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

הבנתי.

בקשר לשפות אין שום סיבה שיהיה מזהה, אבל אם יש יותר משפה לעובד, אז צריך טבלה עם מזהה עובד ושם השפה (בלי תיווך של מזהה שפה).

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

[dovid]

@www אם צפויים שינויים תכופים ברשימת השפות, פשיטא שיש ליצור להם טבלה משלהם.
אם מדובר ברשימה קבועה של כמה אתה יכול להשתמש בenums.
בעבר אכן יצרו טבלה על כל כזה דבר.

[dovid]

@WWW נזכרתי בעוד דרך מקובלת כשמדובר בכמות גדולה של תכונות, ובפרט אם היא דינמית
לעשות טבלה אחת יחידה עם שלושה עמודות, עמודת סוג, עמודת ערך ועמודת מפתח זר לעובד. וככה אפשר להכניס בעצם אינסוף ערכים אפשריים, כשכל ערך ממלא תא שלם, וגם השאילתות מהירות.
קוראים לדרך הזו EAT
https://en.wikipedia.org/wiki/Entity–attribute–value_model
https://blog.greglow.com/2018/02/19/sql-design-entity-attribute-value-tables-part-2-pros-cons/
אגב, יש כאלה (וורדפרס למשל) שעושים את הטבלה הזאת עם עמודה אחת ומשרשרים בטקסט אחד את הכל, למשל
עובד157.משמרת.2
עובד157.משמרת.3

[avi rz]

@dovid אמר בSQL | ערכים מרובים בעמודה:

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

זה טבלה אחת בשביל הערכים,
ומה עם האפשרויות לכל סוג, כמו ש
@www אמר בSQL | ערכים מרובים בעמודה:

כי אחד יכתוב עבריית ואחד עברית,

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

[WWW]

@dovid אמר בSQL | ערכים מרובים בעמודה:

https://blog.greglow.com/2018/02/19/sql-design-entity-attribute-value-tables-part-2-pros-cons/

פה הוא כותב נגד זה, או שלא הבנתי?

[WWW]

@dovid אמר בSQL | ערכים מרובים בעמודה:

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

ומפתח חיצוני.

בסדר.
מה קורה לגבי לחייב עדכון יום עבודה 1 לפחות? (אילו זה היה בלי טבלה נוספת, אז פשוט הייתי עושה NOT NULL). אני מנחש שתגיד לי להגדיר אילוץ, אין משהו יותר פשוט?

[איש נחמד]

@www אמר בSQL | ערכים מרובים בעמודה:

@dovid אמר בSQL | ערכים מרובים בעמודה:

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

ומפתח חיצוני.

בסדר.
מה קורה לגבי לחייב עדכון יום עבודה 1 לפחות? (אילו זה היה בלי טבלה נוספת, אז פשוט הייתי עושה NOT NULL). אני מנחש שתגיד לי להגדיר אילוץ, אין משהו יותר פשוט?

יש לך את האפשרות לבדוק את זה בקוד לפני שאתה שולח את השאילתה.

[WWW]

@איש-נחמד אמר בSQL | ערכים מרובים בעמודה:

יש לך את האפשרות לבדוק את זה בקוד לפני שאתה שולח את השאילתה.

נו... זה יש לי אפשרות בכל דבר.
ראה בקישור ש @dovid הביא לעיל, מה שהוא כותב על זה.

[dovid]

@www אמר בSQL | ערכים מרובים בעמודה:

@dovid אמר בSQL | ערכים מרובים בעמודה:

https://blog.greglow.com/2018/02/19/sql-design-entity-attribute-value-tables-part-2-pros-cons/

פה הוא כותב נגד זה, או שלא הבנתי?

Pros and Cons זה ביטוי באנגלית שאומר מעלות וחסרונות.
בא נאמר ככה, כמה שזה גרוע אבל הפתרון היחיד והמושלם כשצריך אותו (מאפיינים דינמיים).
בכל מערכת CRM כיום אפשר להוסיף מאפיינים מותאמים אישית כראות עיני המשתמש. במסד רלציוני הדרך היחידה לעשות את זה טוב נראית לי הEAV הזה.

[WWW]

@dovid הבנתי, במקרה שלי אני חושב שעדיף האופציה הראשונה של טבלאות נפרדות, כי זה לא כ"כ דינמי, וגם לפי החישוב החוזר שעשיתי זה לא כ"כ הרבה טבלאות.

מה לגבי זה:

@www אמר בSQL | ערכים מרובים בעמודה:

מה קורה לגבי לחייב עדכון יום עבודה 1 לפחות? (אילו זה היה בלי טבלה נוספת, אז פשוט הייתי עושה NOT NULL). אני מנחש שתגיד לי להגדיר אילוץ, אין משהו יותר פשוט?

יש לך רעיון?

[dovid]

@WWW אני בפרקטיקה עושה מאוד מעט אימותים ובדיקות תקפות בצד המסד.
גם בגלל שאני הרבה יותר מתכנת מאשר DBA, גם בגלל שאני בעצמי המתכנת ולא מישהו זר, וגם בגלל שאני בד"כ צוות של איש אחד, וגם בגלל שלרוב הדברים זה לדעתי נכון יותר.
ראה גם:
https://www.red-gate.com/simple-talk/databases/sql-server/learn/where-in-the-application-should-data-validation-be-done/
https://stackoverflow.com/q/464042/1271037
https://stackoverflow.com/q/26851291/1271037

[dovid]

@www אמר בSQL | ערכים מרובים בעמודה:

@www אמר בSQL | ערכים מרובים בעמודה:

מה קורה לגבי לחייב עדכון יום עבודה 1 לפחות? (אילו זה היה בלי טבלה נוספת, אז פשוט הייתי עושה NOT NULL). אני מנחש שתגיד לי להגדיר אילוץ, אין משהו יותר פשוט?
יש לך רעיון?

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