我不确定是否有一个术语来描述这一点，但我观察到内容管理系统将所有类型的数据存储在一个表中，并且具有最小的属性，而元数据以另一个表的形式存储在另一个表中键值对。
例如。一切（博客文章，页面，图像，事件等）都存储在一个表中，并被视为一个帖子。
据我所知，这允许抽象和易于扩展
我们正在考虑以这种方式设计我们的新项目。它不完全是CMS，但我们计划分阶段向其添加模块。让我们说最初只会发布评论的帖子和图片。稍后我们可能会添加也会有评论功能的视频。
这种方法的缺点是什么？它会像我们这样的要求起作用吗？
由于
答案 0 :(得分：2)
缺点是主表将获得数以万计的读取（以及大量写入）。
这意味着会有很多锁定争用，重型重建索引等。
为了缓解这种情况，您可以考虑在一系列不那么主的表中拆分“主表”。
说，你将有一个主要的“帖子”表（可能通过元数据或特定类型的帖子的子表进行细化，如Sticky，Announcement，Shoutbox，Private ......）
图像的一个主表（可能是为GIF，jpegs等精制而成）
视频的一个主要表......
如果这是一个自定义应用程序（并不打算像CMS或Portal框架那样必须“可无限调整”）我认为这种拆分是可以接受的，并且可以提供更好的性能（如果你期望有大量的数据）。
关于您的“示例”评论...首先，如果您在一个巨大的表格中再次发表评论，您可能会遇到类似的问题，就好像您保留了所有类型的项目一样。 假设这不是问题，你可以使用一种引用键（当然不能使用正常的外键）将注释链接到原始项目。
当您从项目转到评论时，这种方法很有效，当您必须从评论移动到原始项目时，这样做会少一些。所以权衡是关于什么样的操作会更频繁地解决你的问题。
答案 1 :(得分：1)
简单性和可扩展性确实经常是属性值的有吸引力的方面，并且（如你所说）“单一事物表”的方法。
此处没有 100％正确答案 - 根据您的性能/吞吐量目标和可扩展性需求，此方法也可能对您有用。
但是，在大多数情况下，如果您知道要存储的数据类型，通常需要将不同的实体建模到自己的表中并相应地关联数据。 RDBMS已经过几十年的架构和改进，以满足这个用例，并且简单地使用表作为通用转储基础通常不会给您带来任何明显的优势，除非延迟不可避免地需要对数据进行正确建模。此外，当您将所有内容都放入一个表格中时，您可以强迫用户在您的应用程序之外（如果您有任何人，例如报表编写者）必须与您的“模型中的模型”进行斗争，这可能会让人们感到沮丧你将沉到最低的公分母 - 如果你想优化关于类型X的查询，并且你在成群结队的同一个表中有类型Y和Z，它们将影响查询X的性能。
同样，要明确的是，“一个表中的所有内容”名称/值样式元数据方法都有明显的好处。我自己使用它们并出于类似的原因而反对建模。但是，我的建议是将自己限制在你真正需要这样做的时候（即，你需要先实现一些东西，然后才能正确地建模你需要的东西）。最典型的是，当我正在对复杂的系统进行原型设计时，我发现自己正在这样做，而且我需要尽早获得一些东西。