אפיון dataBase
-
יש לי דטהבייס שמנהל עסק של תיווך מוצרים
ישנם לקוחות וישנם ספקים
לפני שני דרכים לאפיון
א. טבלה אחת של אנשי קשר עם שדה של סטטוס ספק / ולקוח
ב. טבלת אנשי קשר ושני טבלאות נוספות של ספקים ולקוחות המקושרות לID של האיש קשר
במקרה הזה יש פה איזה משהוא מענייני ירושה שהרי כל ספק או לקוח הוא איש קשר ונתונים אלו הוא יכול לשאוב מטבלת האנשי קשר
על מה הייתם ממליצים?פורסם במקור בפורום CODE613 ב11/03/2014 12:35 (+02:00)
-
תלוי.
אם כל לקוח יכול להיות גם מוכר (נראה לי שבeBay זה ככה) אז ברור שהדרך הנכונה היא סעיף ב.
אם לא, נחלקו הפוסקים בזה, ואני סובר כדעת המיקלים (או המחמירים) - ליצור 2 טבלאות נפרדות.
כשתצטרך לחבר את הנתונים מ2 הטבלאות תשתמש בUNION.ויש חולקים.
והנלע"ד כתבתי.בחירות נעימות...
קליקOneפורסם במקור בפורום CODE613 ב11/03/2014 13:02 (+02:00)
-
כן ישות הוא איש קשר בין אם הוא ספק, לקוח, מתווך, שנורר או חתול בית. לכולם יש כתובת, טלפון, פקס, עם כולם יש דרכי התקשרות כלשהם, כשתתחיל לבנות אחר כך מחלקות, למיילים SMS ועוד, תמצא את עצמך לפני שוקת שבורה. אל תעשה את הטעות בשום אופן לעשות אותם בשני טבלאות. זה נוגד את כל התיאוריה של מסד נתונים יחסי.
פורסם במקור בפורום CODE613 ב11/03/2014 14:41 (+02:00)
-
מה הבעיה לעשות שני שדות בוליאנים 1. האם ספק. 2. האם לקוח.
בעיקרון אני מסכים עם ClickOne. אמנם לפי דבריך די בשדה כ/ל אחד ואם אינו "כן" אזי הוא שייך לקבוצה השניה.
פורסם במקור בפורום CODE613 ב11/03/2014 19:01 (+02:00)
-
מה הבעיה לעשות שני שדות בוליאנים 1. האם ספק. 2. האם לקוח.
וכשירצו לחלק את הלקוחות לעוד מחלקות יצטרכו עוד 10 שדות בוליאניים, וכשירצו להוסיף לכל מחלקה של לקוחות עוד קטיגוריה, אז זה 10*2 מה נהיה??? אתה עונה לו בראש של json שם אתה יכול לעשות מה שבא לך ולדחוף ערכים מכל סוג בכל זמן, מדובר על מסד נתונים יחסי, יש לו חוקיות משלו, ולא סתם בנו אותו ככה, החומר מסודר בדיסק הקשיח פיזית בצורה שתוכל לאחזר שאילתות ביעילות.
ושמואל עליך לזכור! מסד נתונים שאתה מתחיל אותו עקום, אתה עלול לסבול ממנו הרבה מאוד, אם אתה לוקח לפי שעה, הלקוח שלך יסבול מחור בכיס, אבל גם אתה באופן אישי תסבול הרבה. ראה הוזהרת!!! אני מאוד חריף בדברים האלו, כי ראיתי הרבה תאונות, יש ארגונים שקוראים לי כאילו הייתי ניידת טיפול נמרץ להציל את המערכת הקורסת שלהם, למעשה אני חושב שלתוכנות כאלו צריך זק"א, תוכנה שנבנתה במשך שנים בצורה עקומה, נראית ממש כמו אחרי פיגוע ואני אומר את זה בלי קריצה.... זה פרנסה של אנשים וזה ענין חשוב שצריך לשים לב אליו!!
פורסם במקור בפורום CODE613 ב11/03/2014 20:00 (+02:00)
-
וכשירצו לחלק את הלקוחות לעוד מחלקות יצטרכו עוד 10 שדות בוליאניים, וכשירצו להוסיף לכל מחלקה של לקוחות עוד קטיגוריה, אז זה 10*2 מה נהיה???
אם זה המצב צריך לעשות טבלת אנשי קשר עם כמה שדות בסיסים כמו שם כתובת וטלפון בלבד, ועוד טבלה של ספקים עם עמודת מפתח זר מאנשי קשר ועוד שדות רלונטיים לספקים וטבלה נפרדת של לקוחותעם עמודת מפתח זר מאנשי קשר ועוד שדות רלונטיים ללקוחות.
ואז אפשר להוסיף כשצריך עמודת קטגוריה לכל אחת מהטבלאות הנ''ל לפי הצורך, וכך יהיה אפשר לשלוף איש קשר לפי היותו ספק/לקוח, ו/או היותו בקטגוריית ספקים/לקוחות/אנשי קשר מסויימת.פורסם במקור בפורום CODE613 ב11/03/2014 20:10 (+02:00)
-
@magicode
מה הבעיה לעשות שני שדות בוליאנים 1. האם ספק. 2. האם לקוח.וכשירצו לחלק את הלקוחות לעוד מחלקות יצטרכו עוד 10 שדות בוליאניים, וכשירצו להוסיף לכל מחלקה של לקוחות עוד קטיגוריה, אז זה 10*2 מה נהיה??? אתה עונה לו בראש של json שם אתה יכול לעשות מה שבא לך ולדחוף ערכים מכל סוג בכל זמן, מדובר על מסד נתונים יחסי, יש לו חוקיות משלו, ולא סתם בנו אותו ככה, החומר מסודר בדיסק הקשיח פיזית בצורה שתוכל לאחזר שאילתות ביעילות.
ושמואל עליך לזכור! מסד נתונים שאתה מתחיל אותו עקום, אתה עלול לסבול ממנו הרבה מאוד, אם אתה לוקח לפי שעה, הלקוח שלך יסבול מחור בכיס, אבל גם אתה באופן אישי תסבול הרבה. ראה הוזהרת!!! אני מאוד חריף בדברים האלו, כי ראיתי הרבה תאונות, יש ארגונים שקוראים לי כאילו הייתי ניידת טיפול נמרץ להציל את המערכת הקורסת שלהם, למעשה אני חושב שלתוכנות כאלו צריך זק"א, תוכנה שנבנתה במשך שנים בצורה עקומה, נראית ממש כמו אחרי פיגוע ואני אומר את זה בלי קריצה.... זה פרנסה של אנשים וזה ענין חשוב שצריך לשים לב אליו!!
זה תלוי בסוג הערך. אתה מסכים איתי שיש ערכים שלא תשים אותם בטבלת מאפינים.
כאילו לפי נשמע מדבריך נעשה טבלה אחת עם id בלבד.
טבלה שניה עם שלוש שדות.
- מפתח זר לid של הטבלה הקודמת. 2. סוג מאפיין 3. ערך מאפיין.
ואם בא לכם תוסיפו גם id של מספר אוטומטי.
וככה תעשה שם פרטי משפחה. וכו'.
אתה תסכים איתי שיש ערכים כמו שם פרטי ומשפחה שהם בסיסים. ולא היית עושה אותם בצורה כזאת.
פורסם במקור בפורום CODE613 ב11/03/2014 20:18 (+02:00)
- מפתח זר לid של הטבלה הקודמת. 2. סוג מאפיין 3. ערך מאפיין.
-
אתה תסכים איתי שיש ערכים כמו שם פרטי ומשפחה שהם בסיסים. ולא היית עושה אותם בצורה כזאת.
יש כלל זהב מאוד פשוט בדבר הזה (וכמו שרגילים לומר זקני יפן, תמיד תזכור את כלל הזהב, מי שיש לו זהב הוא קובע את הכללים)
בטבלה הראשית ניתן ערכים שהם:- נפוצים (לכל אחד יש שם משפחה, וגם אם זה חברה מקובל להכניס את שם החברה בשדה שם משפחה)
- לא חוזרים על עצמם בוריאציות שונות (אני מניח שאין לבן אדם 2 שמות משפחה אבל לבן אדם יש הרבה מספרי טלפון, כתובות בבית ועבודה וכדומה)
- בטבלה זו כולם או רובם שווים בהתייחסות לנתון מבחינת הרלוונטיות שלו לנושא הטבלה (למשל לרוב האנשים בטבלה יש שם פרטי, ואפילו שם בת זוג אולי למעט חברות וכדומה שזה לא רלוונטי, אבל אם חשבונות בנק רלוונטיים רק לספקים למשל, אז עושים טבלה של חשבונות בנק, ולא שדות של פרטי בנק בטבלה הראשית)
פורסם במקור בפורום CODE613 ב11/03/2014 21:22 (+02:00)
-
האמת היא שאני הכי מזדהה עם דברי ארכיטקט
טבלה אחת בסיסית של אנשי קשר ופרטים מיוחדים של ספק ישמרו בטבלת ספקים עם מפתח זר וכנ"ל לגבי הלקוחות
רק שיש כאן שני אפשרויות לייחס את המפתח הזר
א. לטבלת ספקים ומשם לגשת לטבלת אנשי קשר כדי לקחת נתוני איש קשר
ב. לייחס לטבלת אנשי קשר וכאשר אני ירצה פרטי ספק לגשת לטבלת הספקיםפורסם במקור בפורום CODE613 ב12/03/2014 11:35 (+02:00)
