使用什么数据库系统？（带 FK 的 EAV？）答案

【问题标题】：What database system to use? (EAV with FK?)使用什么数据库系统？（带 FK 的 EAV？）
【发布时间】：2012-03-20 18:50:13
【问题描述】：

我正在开发一个应用程序，我想知道哪种数据库最适合我。

我正在尝试对列表进行建模，但属性/结构因区域设置而异。我想在不同的语言环境特定结构中比较、搜索等这些列表/属性。始终可以选择为每个语言环境创建一个表，但最好引用 price = 100 之类的东西而不是 price_us = 100 OR price_de = 100 OR etc..

我在这里阅读了很多关于 MySQL 中 EAV 的问题，似乎它对我来说可能不是一个理想的解决方案（属性数量；过于复杂）。

有没有什么东西可以让我既灵活又像 FK 约束？（仅限于某些属性或值？）

【问题讨论】：

EAV 有什么问题？它始终是最好的方法，尤其是当您的项目比预期的要大时。它是一种逻辑结构，易于理解和处理。
你考虑过分成价格和货币吗？
@Andreas 这太笼统了。您能以任何方式支持或支持该主张吗？
Andreas 说What's the problem with EAV? It is always the best approach, especially, when your project gets bigger than expected. It is a logic structure and easy to understand and handle. 你认为股市数据库是EAV 吗？银行使用 EAV 吗？一切都有它的位置，但是说 EAV 是 always the best approach 简直太荒谬了，几乎就像说所有列都应该是字符串一样疯狂。
@Andreas：YMMV 但在大多数情况下，EAV 模式被认为是性能和维护的定时炸弹，这是有充分理由的。每个有兴趣的人都应该查找dba.stackexchange.com/questions/3492/…和thebuild.com/blog/2011/02/25/10-ways-to-kill-performanc

标签： mysql database database-design nosql entity-attribute-value

【解决方案1】：

好吧..我会选择类似的东西：

Products           Locales              Prices
----               -----------          -----------
product_id PK      locale_id PK         product_id FK
name               title                locale_id FK
descriptions                            amount
                          if needed >>  currency_id FK

似乎是一个合理的结构。对于Prices 表，PRIMARY KEY 将是复合的。

至于选择所有数据的产品：

SELECT
    Procucts.product_id
    Products.name
    Price.amount
FROM Products
    LFFT JOIN Prices USING(price_id)
    LEFT JOIN Locales USING(locale_id)
WHERE Locale.title = 'uk'

【讨论】：

【解决方案2】：

EAV 建模被认为是一种 sql 反模式，并且有许多正当理由，尽管它在某些领域（例如临床系统）中是可行的并且相当普遍。然而，它违反了关系数据库所基于的许多原则（因此称为反模式），并增加了查询的复杂性/开销，同时也难以维护数据的关系上下文。

也许几年前，除了在 MySQL 中实现这种模式外别无选择，事实上我曾在一个选择这种方法的系统上工作过。然而 12 个月前，我们切换到了无模式后端 (mongoDB)，它非常适合存储具有可变属性的记录。

恕我直言 - 如果您正在考虑在 MySQL 中实现 EAV 模式，请首先考虑无模式数据库架构。

【讨论】：