创建在所包含的数据类型上没有差异的语义SQL表是错误的吗？

为了便于讨论，假设我有用户表和项目表

User
----------
id
userName

Item
----------
id
itemName
cost

然后，为了实现一个解决方案，找出用户已经拥有的项和用户想要的项，我使用外键创建了另外两个表

User_ItemOwned
----------
id
userId (fk)
itemId (fk)

User_ItemWishlist
----------
id
userId (fk)
itemId (fk)

从表面上看，除了表的名称之外，这些表似乎是相同的。这让我觉得很奇怪，并引出了一个问题——从数据库设计的角度来看，两个数据库表存储相同的数据类型，但完全基于表的标题而存在绝对不同，这本身就有问题吗？更有效的设计是使用一个具有状态类别（Wishlist或Owned）的单用户项目表吗？

项目（Owned/Wishlist）的状态对用户而言是用户项目关系的一个属性。因此，两个表中的数据应存储在一个表中，状态为另一列。 此外，如果将来会有更多这样的状态，那么在state列中只允许有额外的值

---

如果您确实希望有单独的表名（问题中不清楚动机），可以使用适当的过滤器在表的顶部创建视图。嗯。

这有什么不对？随着时间的推移，每个表可能以不同的方式演变。你总是可以有一个像“list_type”这样的字段，它要么是

拥有的

要么是

愿望列表

，但这也行得通。我问这个问题主要是因为我无法找出这个设计的错误，但正如维克多在下文中指出的，如果一个用户项所处的状态数量增加，那么为每个状态类别创建一个新表的规模就很小。然而，您提出了一个很好的观点，我认为允许表随时间变化并捕获特定于某个类别的数据的灵活性会带来一些好处。也许这只是重复工作量（多个用户\项目样式表）与灵活性的利弊对比的一个例子这是一个“它真的取决于”类型的问题。如果愿望列表的演变方式是您有多个愿望列表，如果“拥有”也有其他属性，那么这些表将出现分歧。如果它们要么在列表中，要么在列表中，那么这实际上是一个通用的“AddItemtoList”表，其中列表是“owned”和“wishlist”。您必须考虑这些功能的作用，以及它们随着您的业务需求随着时间的推移而发展的可能性。我欣赏这一见解，我认为这可能归结为简单性（单一类别）与灵活性（能够添加特定于特定用户项关系类型的附加数据）的问题。我认为我所处理的“气味”是明显的重复，但这并不是天生的错误。如果每个类别都有额外的属性，那么有多种方法来模拟这种关系。例如，您可以从继承的角度查看类别，并使用每个具体类模型的表，其中所有公共属性都在一个公共表中，每个类别的特定属性都存储在单独的表中@WhatsInAName