如何知道何时为非常相似的对象类型创建新表格？你怎么知道你什么时候需要单独的表格？
例如：
学习mysql我正在构建一个模型太阳系。就我的项目而言，行星与矮行星，半人马和彗星有许多相似的属性。矮行星几乎与行星完全相同。半人马和彗星只有不同于行星，因为它们的轨道有更多的变化。我应该为每种类型的对象都有一个单独的表，还是应该共享表？
这个例子可能太简单了，但我也对最佳实践感兴趣。就像我应该使用单独的表格，以防万一我想在未来使行星和矮行星变得不同，或者它们是将它们保持在同一个表中的任何效率原因。
Normal forms是你应该感兴趣的。他们几乎是建立表格的惯例。
任何不会破坏first，second或third正常形式的设计对我来说都很好。这是一个相当长的需求清单，所以我建议你去阅读上面的维基百科链接。
这就是所谓的Database Normalization
有很多正常的形式。通过应用规范化，您将会浏览元数据（表格）并更清楚地研究数据之间的关系。通过使用规范化技术，您将优化表以防止冗余。此过程将帮助您了解根据不同字段之间的关系创建的实体。
如果您想要在单个查询中获取行星和彗星，那么如果您希望数据库能够高效工作，它们几乎必须位于同一个表中。继承应该在你的应用程序本身内部进行处理:)
这取决于你想要存储的关于对象的信息类型。如果所有这些信息都是相同的，比如说轨道半径，质量和名称，那么你可以使用同一张表。然而，如果每个属性都有不同的属性（比如说行星等的大气成分），那么你可以为每个属性（不是非常规化的）使用单独的表格，或者为轨道，质量和名称等基本属性使用一个表格，第二个表格只是行星所特有的属性（如果需要的话还有类似彗星的表格等）。所有对象都在第一个表中，但只有行星会在第二个表中，并通过外键链接到第一个表。
你应该最有可能拆分有关行星的数据等，以便共享（公用）信息在另一个表中。
E.g.
Common (Table)
Diameter (Column)
Mass (Column)
Planet
Population
Comet
Speed
我认识的柱子很差。 Planet和Comet表格通过一个键链接到Common数据。
这绝对是一个主观问题。这听起来像你已经在正确的思路上。我会问：
你也可以问问自己，你将如何来查询数据。你会想要把他们都放在同一个列表中吗？将数据与其他通常被查询的数据结合到表中总是一个好主意。例如，如果您通常想要查询所有附件，则可以使用“附件”表格，其中的文件可以是图片或视频，而不是图片和视频表格。除非有很好的理由，否则不要拆分为多个表格。
这里是我的回答类似的问题，我想在这里也适用：
有许多不同的方式来表达你的关系模型继承。例如，您可以尝试将所有内容压缩到一个表中，并且有一个允许区分不同类型的字段，或者具有一个共享属性表以及具有特定属性等的子表的关系。你仍然存储相同的信息。从领域模型走向关系模型时，这就是所谓的阻抗失配。两种选择都有不同的折衷，例如一张表可以更容易查询，但多张表的数据密度更高。
根据我的经验，最好不要尝试回答从数据库的角度来看这些问题，但让你的域模型，并选择有时候你的应用程序框架，推动表结构。当然，这并不总是一个可行的选择，特别是在表演方面。
我建议你先在纸上画出你要表达的关系，然后从那里开始。你选择的表格结构是否准确表示域名？是否可以查询提取您想要报告的信息？你写的查询是复杂还是缓慢？回答这些问题以及像他们这样的其他人将有希望引导您创建一个良好的关系模型。
我也建议对数据库规范化阅读，如果你是认真学习的好关系建模校长。
我可能就会有一个叫[HeavenlyBodies表或一些这样的事情。然后有一个与身体的类型，即星球，彗星，小行星，明星等查找表。所有将共享类似的东西，如名称，大小，重量。到目前为止，我阅读的大多数答案都有很好的建议。规范化是好的，但我觉得有时候你可能会做得太过分。第三次正常是一个好目标。
或创建一个空间对象表，其中包含公共信息和分类表，其中包含特定于对象类型的不同分类和说明。如果您需要进一步的分类信息，您可以为不同的分类类型创建更多的表格。 – 2010-01-20 20:25:35