是根据应用程序建模数据库更好，还是根据组件建模数据库更好？
我正在构建一个数据库，发现我有两个不同的对象正在尝试建模。每一个都包含相同的内容（一个 varchar 和几个外键），并且在可预见的将来都会这样做。
我（截至目前）将它们放在同一个表中，并带有一个额外的“类型”字段，但我想知道是否有标准做法。
编辑：为了澄清，它们也将以相同的方式使用，唯一的区别在于它们的显示位置/时间。
I'm structuring a database, and found that I have two different objects I'm trying to model. Each one consists of the same things (a varchar and a couple of foreign keys), and will do so for the forseeable future.
I'm (as of now) going to put them in the same table, with an extra 'type' field, but I was wondering if there's standard practice for this.
Edit: To clarify, they'll both be used in the same way as well, with the only differences being where/when they're displayed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
规则如下：
如果对象确实不同并且将以不同的方式起作用，无论它们在实现上多么相似，您都应该将它们放在两个不同的表中。
苹果和橙子。
如果这些对象在同一上下文或聚合中的任何一点进行比较，那么您可以将基类存储在一个带有代码字段的表中，并将子类存储在另外两个使用外键的表。*
苹果和橙子的“水果报告”。我们有多少种水果？有多少种水果来自加利福尼亚州？
*注意：实际上有很多方法可以解决数据库中的子类问题。重点不在于你使用哪种策略，而在于你是否将它们视为常见的超类型。
The rule is as follows:
If the objects are truly different and will act in different ways, regardless of how similar they are in implementation, you should put them in two different tables.
Apples and oranges.
If the objects are at any point being compared to one another in the same context or in aggregate, then you store the base class in one table with a code field, and store the subclasses in two more tables using foreign keys.*
A "fruit report" for apples and oranges. How many fruits do we have? How many fruits of any kind come from California?
*NB: There are actually many ways to attack the subclassing problem in a database. The point wasn't so much which strategy you're using as it is you treating them as a common supertype or not.
您可以使用不同的模式来设计数据库。例如，您可以使用每个类型样式设计的表或每个层次结构设计的表来表示对象。每种方式都有优点和缺点，但我还没有看到哪一种是“正确”的方式。
但是，根据您的设计，如果对象本质上相同，我会尝试使用相同的对象并放弃类型列。或者，如果它们确实不同，则似乎外键列将与不同的表相关，因此您希望拥有具有明确定义的主键、外键关联的不同表。
There are different patterns you can use to design a database. For example you can represent objects with a Table per type style design or with a table per heirarchy design. There are pros and cons to each but I haven't seen that one stands out as the "right" way.
However, with your design, if the objects are essentially the same, I would try to use the same object and ditch the type column. Or if they are truly different, it seems like the foreign key columns would be related to different tables, so you'd want to have different tables with clearly defined Primary Key, Foreign key associations.