單個表格中的列太多 - 這是很好的正常形式嗎？

規範化的表應該有較少的數字列，並且可以儘可能具有參考字段。這是正確的方法嗎？列數與正常化過程之間是否有任何關係？單個表格中的列太多 - 這是很好的正常形式嗎？

來源

2009-02-03 Dhana

您應該遵循規範化原則，而不是關注表中列的絕對數量。業務需求將推動實體，他們的屬性和他們的關係，沒有絕對數量是「正確的」。

來源

2009-02-03 12:53:56

有間列數和良好的正常化過程中的任何關係？

總之，沒有。一個3NF規範化表將有儘可能多的列需要，只要該表內

數據是關鍵，整個鍵，並沒有什麼但關鍵取決於（幫幫我吧科德）。

有些情況下（一些）非規範化可能實際上提高了性能，而唯一的實際測量方法是測試它。

來源

2009-02-03 12:56:48

+1的短語：「表中的數據是依賴於鍵，整個鍵，不過按鍵（幫幫我吧科德）。」真是一個偉大的線......我感到驚訝，我以前從來沒聽過。你做這件事或者你有一個來源？ – 2009-02-03 13:23:26

我相信我第一次聽到它在SQL Server 2005聖經中由Paul Nielsen - http://www.amazon.co.uk/Server-2005-Bible-Paul-Nielsen/dp/0764542567/ref=sr_1_1?ie=UTF8&s = books＆qid = 1233667734＆sr = 8-1 我只是做了一個搜索，找不到那個短語，但幾乎可以確定它是來自這裏的 – 2009-02-03 13:29:13

同意的，真棒短語+1。 – RedFilter 2009-02-03 13:41:19

雖然我@ocdecio同意，我也觀察到，被歸一化的數據庫一般都有每個表的列數較少，比一個不是更多的表，在相同的數據存儲需求。類似於代碼味道，給定相當大的應用程序的數據庫味道會相對較少。這可能暗示您的數據可能不是正常形式。在適當的情況下應用規範化規則將緩解這種「氣味」。

來源

2009-02-03 12:59:07 tvanfosson

這是一種您可以使用的方法，如果您覺得您的桌子有太多的字段。例如： -

CREATE TABLE Person 
    Person_ID int not null primary key, 
    Forename nvarchar(50) not null, 
    Surname nvarchar(50) not null, 
    Username varchar(20) null, 
    PasswordHash varchar(50) null

在該表中的人，但顯然不是所有的人都需要有用戶因此用戶名和PasswordHash字段爲空。然而，它可能會有比用戶多1或2個數量級的人。

在這種情況下，我們可以創建一個用戶表來保存用戶名和PasswordHash領域有一個一對一的關係Person表。

您可以通過查找套可空字段，要麼空在一起有共同價值觀和顯著可能是空推廣這一做法。這表明您可以提取另一張表格。

編輯

得益於斯蒂芬妮（見註釋）這種技術顯然是被稱爲「垂直分區」

來源

2009-02-03 13:12:14 AnthonyWJones

每一列必須有主鍵的直接和獨家合作關係。如果你有一個屬性很重的項目，那麼你可以做的只是簡化模型。任何分裂成多個表的嘗試都會產生反作用，毫無意義。

來源

2009-02-03 13:28:58 paul

單個表格中的列太多 - 這是很好的正常形式嗎？

回答

相關問題