Database-Design
數據庫中的無模式數據?
我想知道是否有任何數據庫技術不需要預先定義其結構或模式?例如,它可能從一列或一行開始,當使用者認為有必要時,他們會不斷向表中添加更多列和行。
如果您正確編寫查詢並避免,
SELECT *
那麼任何關係數據庫都將允許添加更多列或表,而無需對應用程序進行調整。當然,您必須在 SQL 中引用每一列之前向 DBMS 聲明它。我發現 NoSQL 是“無模式”的說法有點誤導。使用 NoSQL 持久性的應用程序確實有一個模式。不同之處在於模式保存在應用程式碼中,並且在應用程序的整個生命週期中接觸程式碼的每個程序員都有責任強制實施該模式。使用關係數據庫,資料結構被聲明給服務,然後它負責永遠執行這些規則。NoSQL 真正的靈活性在於同一個“桶”中的兩行(其定義取決於您的 DBMS)可以具有不同的結構。
目前有兩種非常流行的方法。
- JSON SQL:2016,
使用 SQL 2016,我們有一個標準化的無模式類型,
JSON
. 大多數數據庫都實現了它,並且許多數據庫也有它的二進制形式(如PostgreSQL和MySQL)。如果此表格可用,您應該使用它。它比 EAV 有更好的類型,並且更容易被索引。它可以進一步支持層次結構,更易於查詢,並且可以在 JSON apis 和 REST 協議中使用。CREATE TABLE foo ( foo_id int, name text, other_data jsonb ); INSERT INTO foo VALUES ( 5, 'foo', '{"json_key":5,"foo":"baz"}' ); SELECT * FROM foo WHERE other_data @> '{"foo": "baz"}';
- EAV - 實體屬性值使用此方法創建一個表示鍵值關係的表,
CREATE TABLE entity ( entity_id, name text ); CREATE TABLE eav ( entity_id int, attribute text, value text );
您可以進一步使用連結表,
CREATE TABLE entity ( entity_id PRIMARY KEY, name text ); CREATE TABLE eav ( eav_id int PRIMARY KEY, attribute text, value text ); CREATE TABLE eav_entity ( eav_id int REFERENCES eav, entity_id REFERENCES entity );
這裡的想法是
attribute
(鍵)和值在它們自己的表中。這樣做的缺點是attribute
s 必須都共享相同的類型。雖然value
s 也必須共享相同的類型,但它們的類型不必與attribute
s 相同。