אפיון dataBase

[רחמים]

לקליק און יש תשובה ניצחת למה שכתבת.

פורסם במקור בפורום CODE613 ב11/03/2014 16:10 (+02:00)

[magicode]

מה הבעיה לעשות שני שדות בוליאנים 1. האם ספק. 2. האם לקוח.

פורסם במקור בפורום CODE613 ב11/03/2014 16:52 (+02:00)

[macroshadow]

@magicode

מה הבעיה לעשות שני שדות בוליאנים 1. האם ספק. 2. האם לקוח.

בעיקרון אני מסכים עם ClickOne. אמנם לפי דבריך די בשדה כ/ל אחד ואם אינו "כן" אזי הוא שייך לקבוצה השניה.

פורסם במקור בפורום CODE613 ב11/03/2014 19:01 (+02:00)

[רחמים]

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

פורסם במקור בפורום CODE613 ב11/03/2014 19:02 (+02:00)

[ארכיטקט]

@magicode

מה הבעיה לעשות שני שדות בוליאנים 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]

@ארכיטקט

@magicode
מה הבעיה לעשות שני שדות בוליאנים 1. האם ספק. 2. האם לקוח.

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

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

זה תלוי בסוג הערך. אתה מסכים איתי שיש ערכים שלא תשים אותם בטבלת מאפינים.

כאילו לפי נשמע מדבריך נעשה טבלה אחת עם id בלבד.

טבלה שניה עם שלוש שדות.

1. מפתח זר לid של הטבלה הקודמת. 2. סוג מאפיין 3. ערך מאפיין.
   ואם בא לכם תוסיפו גם id של מספר אוטומטי.

וככה תעשה שם פרטי משפחה. וכו'.

אתה תסכים איתי שיש ערכים כמו שם פרטי ומשפחה שהם בסיסים. ולא היית עושה אותם בצורה כזאת.

פורסם במקור בפורום CODE613 ב11/03/2014 20:18 (+02:00)

[ארכיטקט]

@magicode

אתה תסכים איתי שיש ערכים כמו שם פרטי ומשפחה שהם בסיסים. ולא היית עושה אותם בצורה כזאת.

יש כלל זהב מאוד פשוט בדבר הזה (וכמו שרגילים לומר זקני יפן, תמיד תזכור את כלל הזהב, מי שיש לו זהב הוא קובע את הכללים)
בטבלה הראשית ניתן ערכים שהם:

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

פורסם במקור בפורום CODE613 ב11/03/2014 21:22 (+02:00)

[שמואל]

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

פורסם במקור בפורום CODE613 ב12/03/2014 11:35 (+02:00)

[רחמים]

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

פורסם במקור בפורום CODE613 ב12/03/2014 16:51 (+02:00)