我有一個數據庫存儲顧客關於產品的查詢。數據庫：表應始終標準化並具有主鍵？
查詢參考（文本），產品號（int）和修訂號（int）一起唯一標識銷售和客戶之間的單個討論。
因此，每個查詢的具體細節都有很多表格，通過enq，pdt和rev值的組合可以很好地識別。
對於任何字段，CREATE TABLE不使用任何AUTO INCREMENT UNIQUE PRIMARY KEY。
我的問題是，這個數據庫設計是否可以接受？ 應該將表總是正常化嗎？
感謝您的建議。
有沒有必要使用AUTOINCREMENT，但每個表應該有某種類型的PRIMARY KEY。主鍵可以是幾個字段的組合，這些字段一起唯一地標識記錄。如果您明確聲明查詢參考（文本），產品編號（int）和修訂版編號（int）的組合作爲主鍵，則基於您告訴我們的是，設計是可以接受的。一起唯一地標識單個討論。
由於性能原因，人們有時會將數據庫非規範化。如果選擇查詢比插入和更新頻繁得多，並且由於需要加入的表的數量而導致感興趣的選擇查詢返回較慢，則考慮非規範化。
如果您提供的運行速度很慢的特定查詢，您會得到很多具體的建議。
擁有PRIMARY KEY（或UNIQUE約束）將首先確保這些值真的是唯一的，其次，將極大地改進對給定查詢的搜索。
一個PRIMARY KEY意味着創造了(enq, pdt, rev)的索引，並且這個查詢：
SELECT *
FROM enquiries
WHERE enq = 'enquiry'
AND pdt = 'product'
AND rev = 'revision'
將在一個索引查找完成。
如果沒有索引，此查詢將需要掃描整個表格，並且不保證您不會得到重複項目。
除非是非常非常非常特殊的情況（如重度插入的日誌表），否則應始終在表上有PRIMARY KEY。
這是兩個問題。 （1）不需要始終使用自動增量鍵。這很實用，因爲您可以使用它來輕鬆處理您的數據。也沒有重複是不是必須的。 （2）當你爲學校做家庭作業時，正常化是必須的，但如果事情變得艱難，你可以打破它，以便讓你的生活更輕鬆，如果你不危及數據的完整性。
就個人而言，我總是總是有某種形式的所有表的主鍵，即使它是用於沒有別的
至於正常化，我覺得應該爭取規範化表自動incrment數，但實際上，當桌子設計好時，有很多好的理由，但沒有正常化。這就是數據庫設計的「理論」符合現實的地方 - 但知道規範化是什麼，爭取它是很好的，並且當你偏離規則時有很好的理由（相對於對規則的無知或更糟的是忽略了好的設計規則）。
我從這個牛羣中分裂出來。請勿將您的查詢參考（文本），產品編號（int）和修訂號（int）作爲主鍵。您表示查詢參考是一種文本類型，您的意思是它將是25或50或500個字符？如果主鍵是由這些字段組成的，則它在我的視圖中將會過於寬泛，因爲它將被附加到爲該表創建的每個索引，從而增加每個索引行的大小，以三個字段的大小和任何需要使用的表回到這張表的外鍵還需要三個字段。
使三個字段成爲唯一索引。放置一個自動增量值作爲主鍵並使其成爲聚集索引。將連接回該主表的表格將在內存中佔用很小的空間以將表1中的數據鏈接到表2。
就規範化而言，如果您的數據只有幾千行，甚至50,000或500,000，則無關緊要，規範化與否。當數據開始變得比可用RAM緩存大時，這是一個問題。
設計一個視圖嚮應用程序呈現數據以實現業務規則。設計存儲過程以接受要存儲的數據。設計表格結構以滿足SLA中的響應時間。如果您必須規範化或反規範化或漫遊或索引或獲得更大的服務器以滿足SLA，應用程序永遠不會知道，因爲您始終通過符合業務規則的視圖提供數據。
規範化理論中沒有處理表是否應該有簡單或複合主鍵的問題。信不信由你，「主鍵」的概念不是關係數據模型的一個組成部分。
話雖如此，表應幾乎總是用主鍵定義。主鍵不一定是單列，並且不需要由自動增量填充。就你而言，它可以是三列一起唯一標識一個查詢。
如果一個表沒有聲明主鍵，它可能以重複行結束。包含重複行的表格表示一組元組，而不是一組元組。一旦處理袋子而不是集合，關係模型預測的結果就不需要應用。這就是爲什麼防止重複行非常重要。
只需添加到答案中，主鍵就可以唯一地標識表中的每條記錄。因此，如果沒有主鍵，最終可能會有兩個（或更多）相同的記錄。此時，不可能在相同的記錄中更新或刪除單個記錄。 – 2010-12-23 18:02:41