我正在重构一个可怕的交织的数据库架构，并不是它过于规范化了;随着时间的推移变得越来越丑陋，并没有非常好的布局。
有几个表（论坛板，论坛帖子，创意帖子，博客条目）共享几乎相同的数据结构和组成，但仅仅因为它们代表了从应用程序角度看的不同“对象”而分离。我最初的反应是将具有相同数据结构的所有内容放入同一个表中，并在执行select时使用“type”列来区分数据。
我是否通过采用这种“一体化”方法并允许（可能）应用程序的这么多部分访问同一个表来让自己陷入瘫痪？仅供参考，我看不出这个数据库在未来一年左右会增长到超过20mb ......
答案 0 :(得分：1)
基本上有三种方法可以在关系数据库中存储对象继承层次结构。每个人都有自己的优点和缺点。参见：
The book也很棒。运气会有第3章 - “映射到关系数据库” - is available freely as a sample chapter。你可以在那里阅读更多关于权衡的内容。
答案 1 :(得分：0)
我曾经不喜欢这种“一体化”的方法，但几年前我被迫在一个复杂的项目中使用它之后，我成了粉丝。如果正确索引表，性能应该没问题。例如，您需要类型列上的索引来加快排序操作的速度。
我现在通常建议您使用单个表来存储类似的对象。那么唯一的问题是，您是否希望使用子表来存储特定于某种类型对象的数据？这个问题的答案实际上取决于每种对象类型的结构有多么不同，以及您将拥有多少对象类型。如果您有50种具有差异很大的结构的对象类型，您可能需要考虑在主表中仅存储一致的对象部分，并为每种对象类型创建一个子表。
但是，在你的例子中，我认为你可以把它全部放在一张表中。
有关详细信息，请参阅此处：http://www.agiledata.org/essays/mappingObjects.html
答案 2 :(得分：0)
不要过分依赖“应用程序视角”，它往往随着时间的推移而变化。通常，数据库也可以被不同的应用程序访问，并且它通常比所有应用程序都要快......
当simliar对象存储在不同的表中时，原因可能是它们实际上表示相同的域对象，但处于不同的状态，或者工作流中的不同步骤。然后将它们保存在一个表中并添加一些简单的属性来标记状态通常是有意义的。如果工作流程或其改变的任何内容，更改数据库和应用程序也更容易，您可能不需要添加更多表或类。