我正在建立一个非常大的网站，目前它使用了大约13个表格，到它完成时它应该是大约20个。
我想出了一个想法，即更改首选项表以使用ID，Key，Value而不是许多列，但我最近认为我还可以在表格中存储其他数据。
将几乎所有内容存储在一个表中是否有效/智能？
修改：这是一些更多信息。我正在建立一个可能最终成千上万用户的社交网络。当站点启动时将使用MySQL集群我正在使用开发VPS进行测试，但是在启动之前所有内容都将被移动到专用服务器。我对NDB几乎一无所知，所以这应该很有趣：）
答案 0 :(得分：1)
此模型称为EAV（entity-attribute-value）
它可用于某些场景，但是由于更大的记录，更大的数量或连接以及在多个属性上创建复合索引的不可能性，效率较低。
基本上，当实体具有很多非常稀疏（很少填充）和/或在设计时无法预测的属性时使用它，如用户标签，自定义字段等。
答案 1 :(得分：0)
当然我不太了解大型数据库设计，但从我所看到的，即使是非常大的应用程序存储它们的东西也是非常少量的表（每个表20GB）。
对我来说，我宁愿在1个表中获得更多信息，因为这意味着数据不会随处乱丢，而且我不必对多个表执行操作。虽然1表也意味着凌乱（通常对我来说，每个对象都会在桌面上，而对象就是你的应用程序逻辑中的对象，比如User类或BlogPost类）
我想我想说的是做任何有意义的事情。不要把信息放在2个不同的表中同一个东西，不要把2个东西的信息放在1个表中。坚持使用1个表只描述某个对象（这很难解释，但如果你做面向对象，你应该理解。）
答案 2 :(得分：0)
没了。首选项应按原样存储（在用户表中） 例如，私人消息无法存储在用户表...
中你不必考虑加入不同的表......
答案 3 :(得分：0)
我首先要说20张桌子不是很多。
一般情况下（很难从你给出的有限信息中说），键值模型的速度并不是那么有效，尽管它可以更有效地进行空间划分。
答案 4 :(得分：0)
我绝对不会这样做。基本上，原因是如果您在一个表中存储了大量数据，那么在不断查询同一个表时，您会看到性能问题。然后考虑一下你需要的查询的连接和复杂性（取决于你的网站）......这不是我个人想要承担的任务。
使用多个表时，它会将数据拆分为较小的集合，并且查询所需的资源较少，作为额外的奖励，它更容易编程！
有一些应用程序可以做到这一点但是它们很少见，如果你有一个包含大量列的大表并且大多数都没有值，它们或多或少。
我希望这会有所帮助： - ）
答案 5 :(得分：0)
我认为项目中的20个表不是很多。我确实看到了你对使用EAV的观点和兴趣，但我不认为这是必要的。我会坚持使用适当的FK关系等3NF中的表格，你应该没问题。）
答案 6 :(得分：0)
简单的答案是20个表不会使它成为一个大数据库而MySQL不需要任何优化。因此，请关注清洁数据库结构和规范化。