SQL Server 中的有點 EAV
所以我需要在數據庫中建構管理員使用者可以在沒有我的情況下添加和刪除模型。我想將模型中的每個欄位放在一個單獨的表中，而不是一個大表中的所有值和所有值的普通類型，以及該欄位需要的任何內容。
因此，一個人的模型範例可能是：
然後數據庫可以包含 3 個表：
- 一個使用 EntityId 和 varchar 來儲存名稱。
- 一個帶有 EntityID 和 Date 來儲存日期
- 一個用EntityId和EntityID指向地址模型
選擇會做很多連接，但我們可以索引需要搜尋的欄位，EntityId 將是一個 int 並且總是被索引。
asp.net 伺服器將保持對模型的控制並建構只選擇他們需要的查詢。
您是否看到任何重大問題，我知道我們不喜歡 EAV，我們現在被鎖定到 sql server。
我不是DBA人…
EAV 的所有實現，即使您有您所描述的那種“元數據表”，也會導致內部平台效應：
內部平台效應是軟體架構師傾向於創建一個可定制的系統，從而成為他們正在使用的軟體開發平台的複製品，而且通常是糟糕的複製品。
您可以在客戶端層中編寫程式碼來實現數據類型和簡單約束等基本事物的強制執行。
例如，您可以將 varchar、date 和 integer 屬性分成三個表，這是對的。或者，您可以創建一個包含 varchar、date 和 integer 三列的單個屬性表，並將您的值儲存在給定屬性的正確數據類型的列中，而其他兩個將為 NULL。
但無論哪種方式，您的客戶端應用程序如何知道要使用哪個表或哪個列？您必須編寫客戶端程式碼來查詢每個欄位的元數據表，並通過條件邏輯建構 SQL 查詢。每次。無論查詢在普通數據庫中多麼簡單，現在它都成為一項重大工作，您最終將編寫查詢模板建構器程式碼的螢幕和螢幕以嘗試使其更容易。
然後，您可能具有給定模型所必需的一些屬性。在正常的表設計中，您只需將一列指定為 NOT NULL。但是在這裡，您必須在元數據表中添加更多列才能將屬性定義為強制屬性。
然後你可能還會考慮每個屬性是否可以有一個 DEFAULT。或字元集和排序規則。或不同的類型，如 DECIMAL。
考慮如何在 EAV 表中為 UNIQUE 約束建模。或 FOREIGN KEY 約束。
最終，您將在數據庫中實現一個數據庫。這就是內部平台效應。
可以做到，但工作量很大，而且你要為不可避免的錯誤負責。完整的關係數據庫需要數十甚至數百工程師年才能實現，而且它們仍然存在錯誤。