想象一个假设的数据库，它存储产品。每个产品都有100个属性，但任何给定的产品只能设置约50个这样的值。我可以看到三种存储这些数据的方法：
包含100列的单个表
一个表格很少的表格（比如10列每个产品都有一个值），另一个表格包含列（product_id，attribute，value）。即，EAV数据存储。
每列的单独表格。所以核心产品表可能有2列，还有98个其他表，每个表都有两列（product_id，value）。
从纯粹的效率角度出发，将这些极端之间的灰色阴影放在一边，最好用吗？我假设它取决于正在运行的查询类型，即大多数查询是针对产品的多个属性，还是针对多个产品的单个属性的值。这对效率有何影响？
假设这是一个使用InnoDB的MySQL数据库，并且所有表都有适当的外键，以及product_id上的索引。想象一下，属性名称和值是字符串，并且没有编入索引。
从一般意义上讲，我问的是，访问一个非常大的表是否需要比具有多个连接的查询更多或更少的时间。
我在这里找到了类似的问题：Best to have hundreds of columns or split into multiple tables?
不同的是，这个问题是询问具体案例，并没有真正告诉我一般情况下的效率。其他类似的问题都在谈论组织数据的最佳方式，我只是想知道不同的组织系统如何影响查询的速度。
答案 0 :(得分：3)
从一般意义上讲，我问的是，访问一个非常大的表是否需要比具有多个连接的查询更多或更少的时间。
加入会比较慢。
然而，如果您通常只查询特定列的子集，并且此子集为"vertically partitioned"到其自己的单独表中，则查询此类“精益” table通常比查询包含所有列的“fat”表更快。
但这是非常具体和脆弱的（随着系统演变而容易分解）的情况，你应该在走下去之前仔细测试。您的默认起始位置应该是一个表。
答案 1 :(得分：1)
通常，您拥有的表越多，您的设计就越规范化，更正确，因此更好（即：减少数据冗余）。
如果您以后发现报告此数据时遇到问题，那么可能需要考虑创建非规范化值以改善任何特定性能问题。稍后添加非规范化值比规范现有设计糟糕的数据库要痛苦得多。
在大多数情况下，EAV是一个查询和维护的噩梦。
大纲设计将包含Products表，Attributes表和ProductAttributes表，其中包含相关条目的ProductID和AttributeID。
答案 2 :(得分：0)
正如您所提到的 - 它严格依赖于将在这些数据上执行的查询。如您所知，连接加剧了数据库。我无法想象为简单的数据读取制作50-60个连接。在我的拙见中，这将是疯狂的。 :)最好的办法是，在Management Studio中引入测试数据并在工具中查看您的特定查询估计执行计划。 MySQL应该存在类似的工具。
我倾向于建议你避免创建这么多表。我想，它必须在未来引起问题。也许可以将很少使用的数据分类为单独的表或使用复杂类型？对于字符串数据，您可以尝试使用非聚簇索引。