Postgresql
Postgres JSONB 的一個很好的案例？
我希望創建一個資產管理系統來跟踪資產（筆記型電腦/台式機、顯示器、鍵盤、滑鼠、包、軟體鍵等），基本上是可以分配給員工的任何東西。我的問題是，每種類型都需要跟踪不同的屬性。我們將跟踪電腦的一組不同的屬性/屬性，而不是監視器。我讀過 EAV 模式（或大多數人所說的反模式），似乎瘟疫應該避免這種情況。創建包含所有列的單個表似乎很荒謬，並且為出現的每種新類型創建一個新表似乎不是最佳選擇。我最近在 Postgres 9.4 中讀到了 JSONB。儲存一個可由應用程序處理的 JSON 對像似乎是一個不錯的折衷方案。
這是 JSONB 的一個很好的案例嗎？或者 EAV 有意義嗎？或者製作一張巨大的桌子，或者為每種類型創建一張桌子？
這確實是儲存類對像或鍵/值數據的合理案例，並且
jsonb在 PostgreSQL 的欄位中將其表示為 JSON 是一種合理的方法。一般來說，當您開始查看應用程序動態添加列的 EAV 或寬表等替代方案時，是時候考慮
hstore,xml,等了。基本上是新的，具有更標準的數據表示方式和嵌套功能，因此在大多數情況下它是可取的。jsonb``jsonb``hstore如果被跟踪的事物是（a）相當靜態且不是使用者定義的，並且（b）不是過多的，則用於不同種類事物的靜態表以及用於更一般類別事物的父表仍然有意義。這聽起來不像這裡的情況。
我仍然建議將屬性保留為正常列，其中：
- 它們構成引用關係的一部分（is-a、has-a、contains、is-contained-by、owns、is-owned-by 等）；
- 它們是
UNIQUE約束有意義的自然鍵；- 它們在大多數查詢中被過濾或以其他方式查詢
您可以在查詢 json 欄位的表達式上定義唯一約束——或者更確切地說，唯一索引。將它們分開通常更清潔。類似地，表達式索引可以幫助您希望保留部分 json 對象的經常查詢的欄位。這確實是最重要的第一點，因為 RI 約束不能引用 json 對象鍵的值。