以下是Eav的一些缺點:
No way to make a column mandatory (equivalent of NOT NULL).
No way to use SQL data types to validate entries.
No way to ensure that attribute names are spelled consistently.
No way to put a foreign key on the values of any given attribute, e.g.
查找表。
你在這里提到的所有事情:
- 數(shù)據(jù)驗證
- 屬性名拼寫驗證
- 強制列/字段
- 處理相關(guān)屬性的銷毀
在我看來,根本不屬于數(shù)據(jù)庫,因為沒有一個數(shù)據(jù)庫能夠像應(yīng)用程序的編程語言那樣在適當(dāng)?shù)募墑e上處理這些交互和需求。
在我看來,以這種方式使用數(shù)據(jù)庫就像用石頭敲釘子一樣。你可以用石頭來做這件事,但你不應(yīng)該用錘子,它更精確,而且是專門為這種活動設(shè)計的嗎?
獲取常規(guī)表格布局的結(jié)果既復(fù)雜又昂貴,因為要從多個行獲取屬性,需要對每個屬性進行聯(lián)接。
這個問題可以通過對部分?jǐn)?shù)據(jù)進行少量查詢并將其處理為您的應(yīng)用程序的表格布局來解決。即使您有600 GB的產(chǎn)品數(shù)據(jù),如果需要來自本表中每一行的數(shù)據(jù),也可以分批處理。
進一步說,如果您想提高查詢的性能,您可以選擇某些操作,例如報告或全局文本搜索,并為它們準(zhǔn)備索引表,這些索引表將存儲所需的數(shù)據(jù)并定期重新生成,比方說每30分鐘一次。
你甚至不需要擔(dān)心額外數(shù)據(jù)存儲的成本,因為它每天變得越來越便宜。
如果您仍然關(guān)注應(yīng)用程序所做操作的性能,則可以始終使用Erlang、C+、Go語言對數(shù)據(jù)進行預(yù)處理,然后只需在主應(yīng)用程序中進一步處理優(yōu)化后的數(shù)據(jù)。