我正计划使用 EAV 设计开发一个应用程序。我对EAV和第六范式做了很多研究。我什至与工作中的人交谈过，他们说如果你关心自己的理智，请避免这两种方法。我有创建包含一千多列的表的想法，但根据这个问题，这可能不是一个好主意。所以我想做的不是在一个表中创建一千列，而是创建一千个“一列”表。这将使我能够将所有列分成“一列”表。这会给我最大的灵活性，但我担心性能会受到很大影响。
- 我的问题是：50 个内部连接（一对一）的查询是否非常慢？该数据库将为公共网站提供动力。
问问题
753 次
4 回答
2
这听起来像是在关系模型之外更好地解决的问题 - 使用xml, json, 数组值或hstore字段，或使用针对此类工作优化的键/值或列存储。
看：
于 2013-02-20T01:44:09.560 回答
1
我在 postgresql 中遇到了实际的默认限制，它是 8 个连接。任何超过 8 的东西都加入了 postgres，你就是在玩火。
更具体地说，join_collapse_limit 默认为 8。如果查询超出 join_collapse_limit 连接，则规划器拒绝重新排序连接。我怀疑计划时间相对于连接数大约为 O(n^2)（因此默认值较低）。您可以将 join_collapse_limit 增加到 1000，但是查询计划会变得非常慢。
所以，是的，在 postgres 中，超过 50 个连接可能是个坏主意。而且我敢打赌，您会在其他数据库中发现类似的限制：在任何平台上优化连接顺序可能大致为 O(n^2)。
于 2013-02-20T00:22:30.710 回答
0
EAV 是整个应用程序的反模式。它应该只用于一小部分应用程序。看到这个： http: //mikesmithers.wordpress.com/2013/12/22/the-anti-pattern-eavil-database-design/
而且，EAV 表将至少有两列，而不是一列。
不过，要回答您的问题-我们不知道。我见过加入 30 个表的查询，而且速度仍然很快。我在一张桌子上看到了非常慢的查询。一些数据库引擎（postgres）甚至不能处理大量的连接，并且一些数据库版本有硬性限制（MSSQL 有 256 个表的限制）。
没有通用的方法来回答这个问题，除了说您几乎总是应该尽可能简单地设计事物，并且使用 EAV 对许多应用程序来说是不必要的复杂性，它们往往会自然地映射到宽表。
于 2014-06-20T18:06:11.343 回答
0
我看不出问题本身。这基本上就是 Vertica 等列式数据库存储数据的方式。不过，肯定有一些考虑因素。
首先，假设您没有跨行进行原子插入、更新和删除。为此类操作管理 1000 个表将是一项挑战。
其次，用于连接的键应该是所有表的主键。我建议不要大于整数。您需要意识到这会为每列插入 4'ish 字节的开销，因此列式数据库最终可能会比列式版本大得多。在其他数据库中，这可以通过在列中进行压缩来缓解。
您还需要意识到还有其他限制，例如视图和表中允许的列数。
假设所有的表都适合内存并且它们在主键上连接，那么性能可能相当不错。
话虽如此，我不确定 1000 个单列表是否真的能得到你想要的。有许多处理宽表的网站和应用程序。很少（任何？）完全将它们分成单列。你这样做有商业原因吗？一般来说，数据库设计应该由业务需求和应用程序需求驱动，而不是由第一、第二或第六范式的概念驱动。
于 2013-02-20T00:13:21.303 回答