無論您使用的是擁有數百條記錄還是數百萬條記錄的數據庫,正確的數據庫設計總是非常重要。 它不僅可以更輕鬆地檢索信息,還可以簡化未來擴展數據庫的工作。 不幸的是,很容易陷入一些可能會使事情變得困難的陷阱。
關於規範化數據庫的主題有整本書,但如果您只是避免這些常見錯誤,那麼您將會走上正確的軌道,進行良好的數據庫設計。
數據庫錯誤#1:重複表中的字段
良好數據庫設計的基本經驗法則是識別重複數據並將這些重複列置於其自己的表中。 在表格中重複字段對於那些來自電子表格世界的人來說很常見,但儘管電子表格設計趨於平坦,但數據庫應該是關係型的。 這就像從2D到3D。
幸運的是,重複的領域通常很容易被發現。 只要看看這個表格:
訂單ID | 產品1 | 產品2 | 產品3 |
1 | 泰迪熊 | 軟糖豆 | |
2 | 軟糖豆 |
當訂單包含四種產品時會發生什麼? 我們需要在表中添加另一個字段以支持三種以上的產品。 如果我們在表格周圍建立了客戶端應用程序來幫助我們輸入數據,那麼我們可能需要使用新產品字段對其進行修改。 我們如何在訂單中找到所有與糖果豆的訂單? 我們將被迫使用可能如下所示的SQL語句來查詢表中的每個產品字段:SELECT * FROM Products WHERE Product1 ='Jelly Beans'或Product2 ='Jelly Beans'或Product3 ='Jelly Beans'。
我們應該有三個表格,每個表格都包含一個獨特的信息,而不是將所有信息放在一起。 在這個例子中,我們需要一個訂單表,其中包含有關訂單本身的信息,包含我們所有產品的產品表以及將產品鏈接到訂單的ProductOrders平板電腦。
訂單ID | 客戶ID | 訂購日期 | 總 |
1 | 7 | 17年1月24日 | 19.99 |
2 | 9 | 17年1月25日 | 24.99 |
產品ID | 產品 | 計數 |
1 | 泰迪熊 | 1 |
2 | 軟糖豆 | 100 |
ProductOrderID | 產品ID | 訂單ID |
101 | 1 | 1 |
102 | 2 | 1 |
請注意每個表格如何擁有自己唯一的ID字段。 這是主鍵。 我們通過使用主鍵值作為另一個表中的外鍵來鏈接表。 閱讀有關主鍵和外鍵的更多信息。
數據庫錯誤#2:在表中嵌入表
這是另一個常見的錯誤,但它並不總是像重複領域一樣突出。 在設計數據庫時,您需要確保表中的所有數據都與自身相關。 這就像那個孩子關於發現不同的遊戲一樣。 如果你有香蕉,草莓,桃子和電視機,電視機可能屬於別的地方。
換句話說,如果你有一張銷售人員表,那麼表中的所有信息都應與該銷售人員具體關聯。 任何不是該銷售人員唯一的額外信息可能屬於數據庫中的其他位置。
SalesID | 第一 | 持續 | 地址 | 電話號碼 | 辦公室 | OfficeNumber |
1 | 山姆 | 埃利奧特 | 德克薩斯州奧斯汀市118 Main St | (215)555-5858 | 奧斯汀市區 | (212)421-2412 |
2 | 愛麗絲 | 工匠 | 第二街504號,紐約,紐約 | (211)122-1821 | 紐約(東部) | (211)855-4541 |
3 | 喬 | 教區 | 428 Aker St,德克薩斯州奧斯汀市 | (215)545-5545 | 奧斯汀市區 | (212)421-2412 |
雖然這張表看起來可能與個別銷售人員有關,但實際上它有一張嵌入表格的表格。 請注意Office和OfficeNumber如何重複“Austin Downtown”。 如果辦公室電話號碼發生變化會怎樣 您需要更新一整套數據以更改單個信息,這絕不是一件好事。 這些字段應該移到他們自己的表格中。
SalesID | 第一 | 持續 | 地址 | 電話號碼 | OfficeID |
1 | 山姆 | 埃利奧特 | 德克薩斯州奧斯汀市118 Main St | (215)555-5858 | 1 |
2 | 愛麗絲 | 工匠 | 第二街504號,紐約,紐約 | (211)122-1821 | 2 |
3 | 喬 | 教區 | 428 Aker St,德克薩斯州奧斯汀市 | (215)545-5545 | 1 |
OfficeID | 辦公室 | OfficeNumber |
1 | 奧斯汀市區 | (212)421-2412 |
2 | 紐約(東部) | (211)855-4541 |
這種類型的設計還使您能夠向Office表添加更多信息,而不會在銷售人員表中創建混亂的噩夢。 想像一下,如果所有這些信息都在銷售人員表中,只需跟踪街道地址,城市,州和郵政編碼就可以完成多少工作!
數據庫錯誤#3:將兩條或更多條信息放入單個字段中
將辦公信息嵌入到銷售人員表中並不是該數據庫的唯一問題。 地址欄包含三條信息:街道地址,城市和州。 數據庫中的每個字段只能包含一條信息。 當您在單個字段中有多條信息時,查詢數據庫信息會變得更加困難。
例如,如果我們想要對奧斯汀的所有銷售人員進行查詢,該怎麼辦? 我們需要在地址字段內進行搜索,這不僅效率低下,而且會返回不良信息。 畢竟,如果有人住在俄勒岡州波特蘭的奧斯汀街上,會發生什麼?
以下是該表的外觀:
SalesID | 第一 | 持續 | 地址1 | 地址2 | 市 | 州 | 壓縮 | 電話 |
1 | 山姆 | 埃利奧特 | 118 Main St | 奧斯汀 | TX | 78720 | 2155555858 | |
2 | 愛麗絲 | 工匠 | 504 2nd St | 紐約 | 紐約 | 10022 | 2111221821 | |
3 | 喬 | 教區 | 428 Aker St | 公寓304 | 奧斯汀 | TX | 78716 | 2155455545 |
這裡有幾件事需要注意。 首先,“Address1”和“Address2”似乎屬於重複性字段錯誤。
然而,在這種情況下,他們指的是直接與銷售人員相關的單獨數據片段,而不是應該在其自己的表格中重複出現的重複數據組。
此外,作為避免的一種獎勵錯誤,請注意電話號碼的格式已從表格中刪除。 盡可能避免存儲字段的格式。 在電話號碼的情況下,人們可以通過多種方式輸入電話號碼:215-555-5858或(215)555-5858。 這將使得通過他們的電話號碼搜索銷售人員或在相同區域代碼中搜索銷售人員更加困難。
數據庫錯誤#4:不使用正確的主鍵
在大多數情況下,您需要為主鍵使用自動遞增的數字或其他生成的數字或字母數字。 你應該避免使用主鍵的任何實際信息,即使它聽起來像是一個好的標識符。
例如,我們每個人都有我們自己的個人社會安全號碼,因此使用員工數據庫的社會安全號碼聽起來可能是一個好主意。 但雖然很少見,但即使是社會安全號碼也有可能發生變化,我們永遠不希望我們的主鍵發生變化。
這是將實際信息用作關鍵值的問題。 它可以改變。
數據庫錯誤#5:不使用命名約定
當你第一次開始設計你的數據庫時,這可能聽起來不是什麼大不了的事,但是一旦你開始寫數據庫查詢來檢索信息,命名約定會幫助你記住字段名。
試想一下,如果名字在一個表中存儲為FirstName,LastName,而在另一個表中存儲first_name,last_name,那麼過程會更困難。
兩種最流行的命名約定是大寫字段中每個單詞的第一個字母或使用下劃線分隔單詞。 您可能還會看到一些開發人員利用除第一個單詞之外的每個單詞的第一個字母:firstName,lastName。
您還需要決定使用單數表名還是複數表名。 它是訂單表還是訂單表? 它是客戶表還是客戶表? 同樣,您不希望陷入訂單表和客戶表。
您選擇的命名約定與實際選擇和堅持命名約定的過程並不重要。
數據庫錯誤#6:索引不當
編制索引是最難的事情之一,特別是對於數據庫設計人員來說更是如此。 所有的主鍵和外鍵都應該被索引。 這些是鏈接在一起的表,所以如果沒有索引,你會看到數據庫性能很差。
但其他領域往往錯過了。 這些是“WHERE”字段。 如果您經常要通過在WHERE子句中使用字段來縮小搜索範圍,則您需要考慮在該字段上放置索引。 但是,您不想過度索引表格,這也會影響表現。
如何決定? 這是數據庫設計藝術的一部分。 對於應該放在桌子上的索引數量沒有限制。 主要的是,你想索引在WHERE子句中經常使用的任何字段。 詳細了解如何正確索引數據庫。