2表：
- 意见
- 下载
相同的结构：
item_id，user_id，time
我应该担心吗？
答案 0 :(得分：11)
我认为本身并不存在问题。
在设计DB时，有许多不同的参数，有些（例如：性能）可能优先。
一个例子：即使结构（我猜索引）是相同的，也许“视图”有更多的记录，并且会更频繁地访问。 仅凭这一点就没有理由不加载下载记录。
此外，他们现在是一个混淆的事实并不意味着他们将来会出现这种情况：观点和下载量毕竟是不同的，所以迟早会有一两个人增加一两个额外的领域。
答案 1 :(得分：6)
这些表现在是相同的，但将来可能会发生架构更改。如果它们代表两个不同的概念，那么将它们分开是很好的。如果您希望将另一个表中的外键添加到下载表而不是视图表，如果它们是同一个表，则无法执行此操作。
答案 2 :(得分：2)
从E / R建模的角度来看，我没有看到它的问题，只要它们代表两个语义上不同的实体。
从实施的角度来看，它实际上取决于您计划如何查询该数据：
在考虑是否将它们合并到一个表格中时，您还应考虑其他因素，例如：
答案 3 :(得分：2)
我认为答案必须是“它取决于”。正如其他人指出的那样，如果一个或两个表的模式可能会发展，那么就没有了。我可以很好地考虑其他情况（通过允许应用程序/用户访问其中一个来简化安全模型）。
话虽如此，我使用遗留数据库，其中 是一个问题。我们为客户发票提供了多个相同的表格。实际上，数据在处理生命周期的不同阶段之间移动。在尝试访问数据时，它会造成复杂的混乱。它可以通过原始模式中的状态标志轻松解决，但我们现在有20多年的代码针对多表版本编写。
简短回答：取决于它们为什么是相同的架构:)。
答案 4 :(得分：1)
Chris Date和Dave McGoveran正式确定了“Principle of Orthogonal Design”。粗略地说，这意味着在数据库设计中，您应该避免在两个不同的relvars中允许相同元组的可能性。目的是避免可能导致的某些类型的冗余和模糊。
可以说，做到这一点并不总是完全可行，并且当原则被打破时，并不一定清楚。但是，我认为这是一个很好的指导规则，只是因为它避免了数据访问代码或约束中重复逻辑的问题，即它是一个很好的DRY原则。避免使用具有可能重叠含义的表，除非存在一些数据库约束以防止它们之间的重复。
答案 5 :(得分：1)
这取决于具体情况 - 什么是View什么是Download？ Download是否意味着View（如何下载）？
可能你有明确的，独立的概念 - 但这是一种我想要进一步调查的气味。看起来很可能是View和Download以某种方式相关，但你的模型没有显示任何内容。
答案 6 :(得分：0)
您是说两个表都有'item_id'主键？在这种情况下，字段具有相同的名称，但具有相同的含义。一个是'view_id'，另一个是'download_id'。您应该重命名字段，以避免这种误解。