יצירת טבלת פירוט
Cascade Delete SQL
varchar(20), nullable, כי לא כל טלפון חייב להישמר ולא צריך תווים בעברית או רוסית.varchar תופס בית אחד לכל תו, לעומת nvarchar שתופס שני בתים, ולכן חוסך זיכרון כשאין צורך בתווים לא-לטיניים.varchar(20), חובה), ועמודת StudentID כמפתח זר (int, לא NULL, כי טלפון חייב להשתייך לתלמיד).varchar(20) לעמודת טלפון.Tools > Options > Prevent Saving Changes That Require Table Recreation - כיבוייה מאפשר לבצע שינוי מבנה שדורש יצירה מחדש של הטבלה (למשל תיקון טעות בסוג העמודה).פרקי ההרצאה: יצירת טבלת פירוט Cascade Delete SQL
תמלול ההרצאה: יצירת טבלת פירוט Cascade Delete SQL
הטקסט המלא של הדקות הראשונות בהרצאה «יצירת טבלת פירוט Cascade Delete SQL» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אנחנו מגיעים לסוג נוסף של טבלאות שקיימות במסד נתונים, סוג, כמובן, סוג לוגי כזה. שוב, מבחינת מסד הנתונים, טבלה זה טבלה זה טבלה.
אנחנו יודעים שמבחינה לוגית זה סוג קצת שונה. בשביל להבין את הסוג, בואו קודם כל נוסיף עוד פרט אינפורמציה לתלמידים.
ומה שאני רואה שיש לי בתלמיד זה קוד חשוב, first name, last name, email, ctid, באיזה עיר הוא גר. ואני רוצה להוסיף גם טלפון. הגיוני שיהיה לי טלפונים של תלמידים.
בואו נלך לדיזיין ונוסיף כאן phone number, מספר טלפון. phone number יהיה לא int מפני שיש אפסים מקדימים וברגע שאנחנו מגדירים int אנחנו מאבדים את האפסים המקדימים.
נראה שאנחנו מגדירים אותו בתור nvarchar אבל כדאי יותר להגדיר אותו כvarchar. מפני שאני לא צריך לשמור תווים בעברית או צרפתית. או ערבית, או רוסית, בתוך המשתנה שלי, כי זה רק מספר טלפון, אז מה יהיה בו?
רק ספרות, אולי גם איזה אות באנגלית, אולי מקף. אין בעיה שזה יהיה ורצ'אר. מיותר שזה יהיה N. ורצ'אר יותר מצומצם בזיכרון מאשר N-וורצ'אר.
ורצ'אר תופס בית אחד לכל תו. N-וורצ'אר תופס שני בתים לכל תו. מן הסתם הוא פי שתיים יותר מצומצם בזיכרון. לכן אגדיר ורצ'אר. לא יודע אם חמישים נראה לי too much, בואו נגדיר עשרים, כמה אנחנו צריכים כבר עבור טלפון ונגיד עלה או נעל.
כן, נגדיר אותו כעלה או נעל כי לא חייבים לספק לי טלפון, נניח לפי המדיניות שלנו, וואלה, לא חייבים לספק טלפון ונבצע save, good ואנחנו רוצים לגשת ולהכניס מידע.
יאללה, בואו נלך לתלמידים, ומה שאנחנו רוצים לעשות זה להגדיר כאן טלפון עבור בארט. נניח גר, אה, בארט, הטלפון שלו זה 03. הוא גר בתל אביב, ובלה בלה בלה בלה בלה בלה בלה בלה.
וליסה, נגדיר לה היא 04, גרה בחיפה, 1234567, מעולה. אבל לליסה יש עוד טלפון. הופה, מה אנחנו עושים?
האם כדאי לעשות פסיק? ולתת לה גם טלפון אחר, יש לה גם נייד, 052. קודם כל הוא אומר לי, תשמע, אתה אמרת שמותר רק 20, אתה לא יכול עכשיו לעשות את זה. אתה לא יכול להכניס לי יותר מ-20 תווים. קודם כל זאת בעיה.
מה נעשה? נגיד אולי שמותר להכניס 100 תווים? מותר להכניס 200? 1,000 תווים? בשביל להכניס הרבה טלפונים? ואם אני מכניס טלפונים, למה פסיק? אולי רווח?
אולי נקודה פסיק? להפריד בין אחד לשני? והתשובה היא כזאת, אנחנו לא מכניסים יותר מערך אחד נתון בודד בתא. מסד נתונים רלציוני אומר כל תא מחזיק לי נתון בודד.
זה יכול להיות מספר קצן או ארוך, זה יכול להיות מחרוזת מאוד ארוכה, אבל היא עדיין נתון בודד. טלפון הוא נתון, שני טלפונים ושני נתונים. אנחנו לא מחזיקים מערך של נתונים בתוך תא בודד במסד נתונים רלציוני.
במסד נתונים שהוא מסוג no sql אין לו טבלאות יש לו שיטות אחרות להחזיק מידע לדוגמה json שם כן אפשר להחזיק מערך טלפונים כתא בודד כי json יכול להחזיק מערך. זה דרך אגב יתרון מאוד גדול שיש למסדי נתונים שהם לא רלציוניים אבל אנחנו במסד נתונים רלציוני טבלאי מאוד נפוץ בעולם טבלאות אין מה לעשות אי אפשר או שזה לא יהיה
נכון זה לא יהיה אפשר. זה לא יהיה נכון להחזיק כמה טלפונים ביחד בתא אחד ויחיד. אז הנה הגענו לאיזושהי בעיה. לפעמים אני רוצה שיהיה לי טלפון בודד, לפעמים אני רוצה שיהיה לי כמה טלפונים לבן אדם, תלמיד, לקוח, ספק, לא משנה מה, ולפעמים אין לו בכלל טלפונים, אולי אין לו טלפון לאותו תלמיד.
אז מה אני בדיוק אמור לעשות כאן? פעם היה פתרון ואמרו כזה דבר, תשמעו, בואו נחזור רגע לפה ונגדיר שזה הטלפון הראשי שלו, מיין פון נאמבר.
ובנוסף, בואו נגדיר סקונדרי פון נאמבר, או מובייל פון נאמבר, או אופיס פון נאמבר. וכבר אתם רואים שיש לי פה צרות צרורות. כמובן, כולם הגיוני שהם יהיו ורצ'או.
למה זה לא כזה נכון? קודם כל, כבר אני רואה פה מורכבות מאוד גדולה. בואו רגע נסגור. ונפתח מחדש אולי, עדיף, כן, צריך לפתוח מחדש.
כבר אני רואה מורכבות מאוד גדולה. לרוב האנשים יש טלפון אחד, אז יש לי פה תאים מיותרים, סתם בזבוז של תאים, מקום, מורכבות סתם גדולה.
ומקרה אחד שהוא לא כזה נכון. מקרה אחר שהוא לא כזה נכון, סיבה אחרת שהיא לא טובה, זה מה יקרה אם תלמיד יבוא יום אחד ויגיד, תשמעו, חבר'ה, לי יש, לא ארבעה, חמישה טלפונים.
בואו קחו את הטלפון החמישי גם, פתאום נגיד לו אין לנו מקום, נגיד לנו רק ארבעה. לכן זה לא פתרון טוב. בואו נחזור רגע לדיזיין וניפטר מכולם.
נלך אחד-אחד ונמחק. delete, תעיף לי את כולם, אני לא רוצה בכלל בכלל שיהיה לי כמה טלפונים ביחד בטבלת התלמידים. מה פותר את הבעיה?
מה שפותר את הבעיה זה טבלה נפרדת מיוחדת לטלפונים, בוא נגיד של תלמידים. לתלמיד יכול להיות מספר טלפונים. הסוג הזה זה לא טבלת ליסטינג כי זה לא רשימה סגורה וקבועה של טלפונים כמו רשימה סגורה של ערים או של מדינות או של מצב משפחתי כלשהו.
בגלל שיכול להיות לתלמיד אפס או יותר טלפונים אז אנחנו בעצם רוצים לפרט את הטלפונים של תלמיד. הטבלה הזאת נקראת Detailing Table או טבלת פירוט והיא מפרטת לנו סדרת ערכים שהיו אמורים להיות בטבלה אחרת, לרוב טבלת בסיס, בדיוק כמו של טלפונים.
אני רוצה עוד עמודה של טלפון לתלמיד, אבל בגלל שיכול להיות לו כמה טלפונים וזה אמור להיות כאילו מערך של טלפונים, אני לא מגדיר מערך בתא, אז אני יוצר בשבילו טבלה נוספת.
אכן כאב ראש לעשות את זה במסד נתונים רלציוני, זה הפתרון, אין כל כך מה לעשות. במקרה הזה כל דבר אחר הוא פחות טוב.
שוב, אם הדאטאבייס הוא לא רלציוני אלא לדוגמה מונגו דיבי, ברור שהייתי מחזיק מערך של טלפונים בתוך התלמיד, כי ג'ייסון יכול להחזיק מערכים, אבל אנחנו לא שם. בואו ניגש לטייבלס ונצרף טבלה.
מפתח כמובן אמור להיות, מפתח ראשי זה יהיה פון איי-די, נגדיר אינט, נוריד על האונל, נסמן מפתח, נגדיר אידנטיטי yes כאן אני רוצה את הפון נאמבר זה יהיה אותו וורצ'אר בגודל 20 חובה לספק לא הגיוני שיביאו לי טלפון לתלמיד אבל לא יביאו
לי את המספר הטלפון מה שאנחנו מסמנים פה זה מפתח זר סטיודנט איי די איזה תלמיד הטלפון הזה שייך אליו בואו נגדיר זה יהיה אינט כמובן אני רוצה שיהיה לי ערך זה לא יכול להיות על האומנל.
לא הגיוני טלפון שלא שייך לאף תלמיד, בדיוק למי הטלפון הזה שייך, חייב להיות של תלמיד. אפשר להוסיף פה עוד דברים, סוג טלפון אולי, האם הוא פעיל כן או לא, אבל נסתפק בזה כרגע.
בואו נבצע שמירה, ויש לנו phones, טבלת טלפונים. עכשיו אנחנו יכולים לגשת לטבלת הטלפונים. רגע, בואו נסתכל על התלמידים ונראה שיש לנו student ID גג 3. בואו נלך לטבלת הטלפון.
רגע איפה היא עושה רפרש הנה היא אה רגע בכלל שכחתי להגדיר ריליישן אוי אוי אוי לפני שאני אוסיף מידע בוא נגדיר את הריליישן בשביל שלא נוכל להוסיף מידע שגוי כאן יהיה הכי קל ללכת פשוט לדיאגרם שלנו רגע איפה הוא נעלם לי אה הנה הוא פה ונוסיף עוד טייבל פורמס ואנחנו רוצים לבצע מתיחה של קו של ריליישן אבל איפה הטבלה שמכילה את המפתח הראשי יש לנו את ה-students
עם student ID יש לנו phones עם student ID אז פה המפתח הראשי נמצא כאן אני גם רואה את הסימן של המפתח בואו נסמן אותו קליק אני לא עוזב לא עוזב לא עוזב את העכבר עד ה-student ID הזה עוזב חשוב שאני ארחף מעליו ולא על מישהו אחר כי הוא יעשה קשר בין מי שאני מרחף עליו עוזב עכשיו הנה הוא אומר לי הפריימרי זה סטודנט סטודנט ID
הפורן זה פורן סטיונט איי-די, אוקיי, והשאלה היא מה אני מגדיר פה. כאשר הטבלה שאנחנו מייצרים היא טבלת דיטיילינג תמיד נבחר כסקיילינג.
וואו, מה זה אומר? אם אנחנו מוחקים תלמיד, ברור שנפטרתי מכל הפרטים של התלמיד שהיו אמורים להיות בטבלת התלמידים.
לא היה לי את השם הפרטי שלו כי מחקתי את התלמיד. לא יהיה לי את השם המשפחה שלו, כי מחקתי את התלמיד. לא יהיה לי באיזה עיר הוא גר, או את האימייל שלו.
ברור שאני לא צריך את הטלפונים שלו. ולכן, אם אני אומר לו קסקייד, המילה קסקייד זה מדורג, בהדרגה. אתה עושה פה, תעשה בהדרגה, גם במקום אחר. תמחק לי גם את הטלפונים שלו מהטבלה האחרת, מטבלת הטלפונים.
זה הדבר הנכון שצריך לעשות בטבלת דיטיילינג, כי הסיבה שיש לי טבלת דיטיילינג, בגלל שיש לי כמה טלפונים לתלמיד אז גם ככה זה נתונים ששייכים ספציפית לתלמיד אני רוצה להיפטר מהם גם כן נעשה את אותו הדבר ב-update למרות שזה פחות משמעות יש לזה פחות משמעות