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