假设您有这些表：RestaurantChains、Restaurants、MenuItems - 它们之间有明显的关系。现在，您有表Comments 和Ratings，它们存储客户对连锁店、餐馆和菜单项的cmets/评级。链接这些表的最佳方式是什么？显而易见的解决方案可能是：
Comments 和 Ratings 中使用列 OwnerType 和 OwnerID，但现在我无法添加外键来链接 cmets/ratings 与它们所针对的对象Comments 和 Ratings 表，例如MenuItemRatings、MenuItemComments 等。这种解决方案的优点是所有正确的外键都存在，但明显的缺点是有很多结构基本相同的表。那么，哪种解决方案效果更好？还是有更好的我不知道的解决方案？
【问题讨论】：
标签： sql database database-design
由于有关菜单项的 cmets 与有关餐厅的 cmets 不同（即使它们碰巧共享相同的结构），我会将它们放在单独的表中，并具有适当的 FK 以在您的数据库中强制执行某些数据完整性。
我不知道为什么会厌恶在您的数据库中拥有更多的表。除非您从 50 个表增加到 50,000 个表，否则不会因为大型目录表而出现性能问题（在这种情况下，拥有更多、更小的表实际上应该会给您带来更好的性能）。我也倾向于认为，在处理名为“Menu_Item_Comments”和“Restaurant_Comments”的表时，比处理名为“Comments”的表更清楚地理解它只是通过它的名字。
【讨论】：
对所有对象都有一个评论/评级表，并且不要使用自动生成的外键。评级表中的键，例如 RatingID，可以放在 Restaurant、Chain、Menuitems 表中的字段中，它们都可以指向同一个表，它们仍然是外键。
如果您需要反过来知道评论与什么对象相关，您需要有一个字段来指定评论的类型，但这应该是全部。
【讨论】：
为 cmets 使用单个表并使用 GUID's 作为您的实体的主键。
然后你可以在不知道它们属于哪里的情况下选择 cmets：
SELECT CommentText
FROM Comments c, Restaurants r
WHERE c.Source = r.Id
SELECT CommentText
FROM Comments c, Chains ch
WHERE c.Source = ch.Id
等等
当然，你不能对 cmets 使用外键，但这并不是说 cmets 不能没有外键。
您可以清理触发器中的孤立 cmets，但如果其中一些被留下也没有什么坏处。
您还创建了一个全局 Entity 表（带有单个 GUID 列），使您的 Chains、Restaurants、MenuItems 和 Comments 使用 FOREING KEY ON DELETE CASCADE 引用该表，当DELETE'ing，比如说，一家餐馆，把它从那张桌子上删除。它会同时删除一家餐厅及其上的所有 cmets，而您仍然保持诚信。
【讨论】：
如果您想利用外键约束并跨基表规范化 cmets（和评级）的属性，您可能需要在基表和 cmets（和评级）之间创建关系表。
例如餐厅和评论：
Restaurants
id (PK)
(attributes of restaurants...)
RestaurantComments
id (PK)
restaurantid (FK to Restaurants)
commentid (FK to Comments)
Comments
id (PK)
(attributes of comments...)
【讨论】：