טעויות נפוצות שנעשו עיצוב מסד נתונים

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

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

טעויות במסד הנתונים מס '1: שדות חוזרים בטבלה

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

למרבה המזל, שדות חוזרים הם בדרך כלל קל לזהות. רק תסתכל על השולחן הזה:

מה קורה כאשר הזמנה מכילה ארבעה מוצרים? היינו צריכים להוסיף שדה נוסף לטבלה כדי לתמוך ביותר משלושה מוצרים. ואם בנינו יישום לקוח מסביב לטבלה כדי לעזור לנו להזין נתונים, ייתכן שיהיה עלינו לשנות אותו עם השדה החדש של המוצר. ואיך אנחנו מוצאים את כל ההזמנות עם Jellybeans בסדר? אנו נאלץ לבצע שאילתה על כל שדה מוצר בטבלה עם משפט SQL שייראה כמו: SELECT * FROM כאשר המוצר Product1 = 'ג'לי שעועית' או Product2 = 'שעועית ג'לי' או מוצר 3 = 'ג'לי שעועית'.

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

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

טעות במסד הנתונים מס '2: הטבעת טבלה בטבלה

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

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

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

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

מסדי נתונים מס '3: לשים שני חלקים או יותר של מידע לתוך שדה בודד

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

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

הנה איך ייראה השולחן:

יש כמה דברים לשים לב כאן. ראשית, "Address1" ו "Address2" נראה ליפול תחת השדות שדות חוזרים.

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

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

טעות במסד הנתונים מס '4: לא באמצעות מפתח ראשי נכון

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

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

וזו הבעיה בשימוש במידע בפועל כערך מפתח. זה יכול להשתנות.

טעות במסד הנתונים מס '5: לא באמצעות אמנת מתן שמות

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

תארו לעצמכם כמה קשה יותר התהליך יהיה אם שמות מאוחסנים כמו FirstName, LastName בטבלה אחת first_name, last_name בטבלה אחרת.

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

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

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

טעות במסד הנתונים מס '6: יצירת אינדקס לא תקין

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

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

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