數據庫規範化：使用單獨的表格存儲單個字段

Question

當前我們的數據庫已設置，以便支付交易記錄支付類型ID，並鏈接到包含這些值的支付類型（現金，支票，信用）表。例如：

付款交易：

• ID
• 金額
• 日期
• 付款類型ID

付款類型：

• ID
• 付款方式（現金，信用卡）

我的問題是我是否應該只是刪除付款類型表，只是店內付款類型值作爲文本支付交易。

這與this question類似。除了支付類型之外，相當確定的是，每個支付類型都不需要添加新數據。 '現金'並沒有與任何東西相關聯，我沒有必要了解現金本身，它只是。

至於我可以告訴利弊和單個現場更換支付類型的表是：

優點

• 刪除一大部分不必要的加入，只要付款類型需要找到。
• 交易的付款類型將始終準確反映交易記錄時的情況。即如果我將付款類型表中的「現金」記錄更改爲「貸記」（無論出於何種原因），所有鏈接至現金的付款交易現在都會與貸記相關聯。

缺點

• 存儲支付類型的文本字段會減慢通過支付類型排序，並做出這樣的排序有點混亂比現在。
• 交易的付款類型將始終準確反映交易記錄時的情況。即如果我有錯別字，付款類型被存儲爲'Kash'，我可以輕鬆修復該錯別字，並且所有鏈接到該付款類型的交易都會自動更新。

我傾向於去除付款類型表並將單個字段添加到付款交易表中，您建議什麼是最佳行動方案？

Answer 1

我不同意你的任何一個贊成論點。

每當支付類型需要找到 時，刪除大多數不必要的連接。

這只是你的假設，這將是一個性能瓶頸。當你有必要的數據時，非規範化是你應該做的事情。這不是其中之一。

交易的付款類型將始終準確地反映在交易記錄時的 。即如果我將支付類型表中的 「現金」記錄更改爲「貸記」（無論原因是什麼 ），則鏈接到現金的所有支付交易現在都將 鏈接到貸記。

您不應該允許某人以這種方式修改付款類型。更改付款類型應該是另一個具有自己時間戳的交易。

任何關係數據庫都可以處理JOIN和規範化表。我擔心你犯了過早的優化。

我會花更少的時間去擔心這個問題，而且會花更多的時間思考如何處理歷史。在將它們移出歷史記錄表之前，您會保留多久的交易？你有沒有想過根據時間戳按月分區數據庫？這將更值得你的努力。

Answer 2

如果刪除PaymentType表，更換了表檢查約束外鍵檢查：

PaymentType CHAR(6) NOT NULL CHECK(PaymentType IN('Cash', 'Credit', 'Cheque') 

OK —你寫「檢查」爲「檢查」;只是英美之間的另一個區別。

現在，這使得找出可能的值是多麼困難;你必須分析系統目錄才能找到答案。使用單獨的表格，您可以檢查單獨的表格以找出允許的內容。假設您開始跟蹤'信用'跟蹤'借記';您將一行添加到表中，而對錶進行模式更改。假設您決定需要記錄未來交易中允許使用哪些代碼（因此'現金'不再是一種選擇）。您可以將一列添加到付款類型表中，以表明該代碼不再有效;用一個簡單的CHECK約束來做到這一點很困難。

因此，即使您目前支付類型表中的數據有限或沒有額外數據，我也會使用支付類型表，而不是將支付類型嵌入到支付交易表中。

雖然是我的設計，但我可能使用CHAR（1）或CHAR（2）代碼作爲付款類型的標識符，而不是數字列。當然，所有這三種類型都以'C'開頭，所以也許你會用'A'表示cAsh，'H'表示cHeck，'R'表示cRedit（也許'D'或'E'表示借記或dEbit）用CHAR（1）代碼;與CHAR（2），你會使用'CA'，'CH'，'CR'（也許'DE'）。全名可以存儲在付款類型表中以用於報告。在這種情況下，好處並不是很大，但是在足夠的記錄（足夠大的足夠小的記錄數量）上節省了4個字節，它可能會成爲存儲成本的一個因素。當然，索引開銷也會起作用。如果Payment Transaction表中的列必須編入索引，那麼較小的字段使用較少的索引空間。