實體特殊屬性和數據庫標準化

Question

假設我有一個擁有所有標準客戶屬性（名稱，地址，聯繫人等）的客戶對象。我們收到一位新客戶（Acme），他有一個非常具體的要求，我們向他們發送的發票上有我們的ID作爲條形碼。我們不希望爲所有其他客戶提供此服務，因此我們打算將此作爲Acme的特例。現在，讓我們假設許多客戶有這些小的一次性請求。什麼將是模式的最佳方式這樣的數據：

我看到一對夫婦的可能性和他們的利益/權衡：

1）硬編碼，在差的點，檢查ID或客戶名稱。
優點：最小的努力，單點集成
權衡：潦草代碼，極易出錯。修改標誌需要新部署。隨着房屋數量的增長，很難找到偏差。

2）每個房產的客戶數據庫列。對於一個客戶標誌將被設置爲true，其餘的爲false。
優點：相對簡單，可以即時更改屬性
權衡：使數據庫非常廣泛，並且使用粗糙的模式。隨着更多屬性的添加，數據將變得越來越難以管理。由於許多不必要的屬性需要映射，因此代碼也會變得不穩定。

3）硬編碼屬性映射。爲客戶提供特殊屬性的地圖。然後可以要求地圖提供特殊屬性，並且代碼流可以從那裏出去。
優點：單點管理。
缺點：硬編碼。客戶編號/姓名將在代碼中。進行更改需要部署。

4）具有鍵/值列的CustomerProperty表。
優點：乾淨。單點管理。動態。
缺點：與其他解決方案相比較複雜。

顯然，選擇會根據具體情況而有所不同。如果我們有數百個偏差，那麼有一個單一的管理點很重要。如果這確實是一次性的偏差，我認爲＃1會好起來的，儘管這很危險。

我有我的意見什麼是最好的在這種情況下......但我想知道其他人的意見。

Answer 1

我會選擇4.從經驗來看，當我選擇了更快的選項時，結果不可避免地實現了最佳解決方案，黑客只會引發問題。我總是試圖從領域的角度來處理這些問題，在這種情況下，4是最好的模型。與維護所有工件以及最終重構相比，實現的差異很小。

Answer 2

我更喜歡完全標準化的方法;我有一張表，列出了不同的一次性特殊請求及其主鍵。然後我有一個連接表，它有兩列，都是外鍵，第一列是客戶的ID，第二列是特殊請求表中的ID。

Answer 3

我在我以前的一個項目上做了很多1），最終轉移到了像4號這樣的解決方案。我使用我的黑客的位置來定製掛鉤。這肯定比較容易管理，特別是隨着定製請求的增長。

我原本以爲2）會適用於您的特定場景（不考慮假定的額外定製請求，只是條形碼請求），因爲我認爲其他客戶也可能最終需要發票上的條形碼。但是，我還可以看到他們希望條形碼信息的格式與您最初爲第一位客戶設計的格式不同，因此這可能會導致您開始使用的問題。

所以我說跟4），並因此實現一個多對多的關係，你的定製實體和你的客戶實體之間。最初，定製實體應該不需要超過值來在您的應用程序代碼中執行開關語句，而定製應該發生。