Sql-Server
一個或多個屬性表
我剛剛花了一些時間與一位同事討論兩種替代數據庫設計，但我不相信。我們倆都不是嚴格的 DBA，所以我們可能會遺漏一些東西。
總體目標是創建為三個（可能是 4 個）實體中的每一個附加開放式自由文本屬性的能力。
我們將業務實體稱為 Device、Location 和 Part；他們之間有關係。
設計 A：創建 DeviceAttribute、LocationAttribute 和 PartAttribute 表，每個表都有一個 ID、Reference ID（對應表的 FK）、Name、Value 和 Type。
設計 B：使用（ID、Name、Value 和 Type 列）和三個引用表創建屬性表 - 每個表都包含從一個實體表到一個屬性表的 ID 的引用。
主要關注的是性能：
- 僅查詢實體數據（例如“給我設備 X 及其所有屬性”）時，3 個單獨的 xxxAttribute 表的性能會更好，還是兩種設計的性能相同？- 在查詢具有給定屬性名稱/值的實體時，1 個屬性表（設計 B）會表現得更好，例如“給我所有具有 Attribute.Name=‘GPS’ 的實體”，還是相當於查詢結合了設計A的3張桌子？- 在設計 B 的情況下：實體表（位置、設備、元件）上的更新是否會導致鎖定其他實體表中的查詢？
系統可能有數万個元件、數千個設備和數百個位置，並且可能必須每秒處理數十到數百個查詢。
我更喜歡一張桌子的幾個原因：
(1) 對於多個表，您幾乎總是在執行聯合，並且您多次為核心數據付費
(2) 您可以輕鬆地針對屬性子集或設備和屬性與索引的組合進行優化，並使用稀疏列來最大程度地減少浪費的空間
我在這裡寫了一些關於 EAV 的文章——它絕不是完美的，但我們在以前的工作中用它來解決許多性能問題（以其他人為代價）。
設計“A”為不需要來自所有 3 個項目（元件、位置、設備）的屬性的查詢提供略高的性能。
設計“B”在編寫查詢、程式碼、文件等時提供了更好的可擴展性並允許更高程度的複雜性。
我傾向於為每種項目類型使用單獨的表格