介紹我一直在閱讀有關(guān)EAV數(shù)據(jù)庫的信息，而大多數(shù)缺點似乎都與EAV設(shè)計確實非常糟糕或很難從數(shù)據(jù)中生成報告有關(guān)。通常，當您看到人們抱怨EAV時，他們使用少于三個的表來嘗試復(fù)制RDBMS中單獨的表+列的功能。有時，這意味著將所有內(nèi)容（從小數(shù)到字符串）都存儲在單個TEXT值列中。EAV還會破壞數(shù)據(jù)完整性的安全保護措施，如果您不小心的話，這可能會很糟糕。但是，EAV確實提供了一種輕松的方式來跟蹤歷史數(shù)據(jù)，并允許我們在SQL和鍵值存儲系統(tǒng)之間來回移動系統(tǒng)的某些部分。如果我們根據(jù)類型區(qū)分不同的實體屬性該怎么辦。除了與特定屬性和實體相關(guān)的正確索引值之外，這還使我們?nèi)匀豢梢蕴幚韇elongsTo，Has，HasMany和HasManyThrough關(guān)系?？紤]以下兩個基本實體products (price -> decimal, title -> string, desc -> text, etc...)    attributes        options            [...]        int        datetime        string        text        decimal        relation            [id,foreign_key]users (gender -> options, age -> int, username -> string, etc...)    attributes        options            [...]        int        datetime        string        text        decimal        relation            [id,foreign_key]RDBMS架構(gòu)設(shè)計眾所周知，用戶資料和產(chǎn)品是世界上最多樣化的產(chǎn)品。每個公司處理它們的方式都不一樣，并且針對他們的需求具有不同的“列”或“屬性”。以下是如何處理多個（嵌套和/或關(guān)系）實體的視圖。想法是，對于每個實體都有此主屬性表，然后該主表指定如何查找和解釋這些值。這使我們能夠處理特殊情況，例如指向其他實體的外鍵以及諸如“選項”或十進制數(shù)字之類的東西。查詢樣例首先，實體是什么“類型”？（用戶，帖子，評論等。）SELECT * FROM entity_type et LEFT JOIN entity e ON e.entity_type_id = et.id WHERE e.id = ?接下來，該實體的屬性是什么？（表屬性）SELECT * FROM attr WHERE entity_id = ?接下來，此實體的屬性中存在哪些值？（attr _ ###表）SELECT * FROM attr_option, attr_int, attr_relation, attr_text, ... WHERE entity_id = ?vsSELECT * FROM attr_option WHERE entity_id = ? if( ! multiple) ORDER BY created_at DESC LIMIT 1SELECT * FROM attr_int WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1SELECT * FROM attr_relation WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1SELECT * FROM attr_text WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1...該實體存在什么關(guān)系？假設(shè)我們有一個ID為34的“發(fā)布”實體，并且我們想要它的“注釋”（entity_type = 2），這可以允許我們在產(chǎn)品實體上獲取評論實體ID：SELECT * FROM entity AS eLEFT JOIN attr_relation AS ar ON ar.entity_id = e.idWHERE ar.entity_id = 34 AND e.entity_type = 2;除了多個查詢（無論如何，鍵值存儲都需要這些查詢）之外，這種方法還會存在哪些問題？