关闭。这个问题是基于意见的。它目前不接受答案。
**想改进这个问题吗?**更新这个问题,这样就可以通过编辑这篇文章用事实和引文来回答。
11个月前关门了。
改进这个问题
假设我有一个类似instagram的社交网络应用程序。对于我的数据库模式,我将执行以下操作:
CREATE TABLE `likes` (
`like_id` int PRIMARY KEY AUTO_INCREMENT,
`user_id` int,
`type` ENUM ('POST', 'COMMENT'),
`target_id` int
);
其中,target\ id是指向特定post或特定评论的外键。这种将post和comment类合并到一个表中并按类型enum区分它们的设计是否糟糕?最好创建两个没有区别的表:commentlikes和postlikes?
请记住,我确实预见到未来可能会在应用程序中添加更多他们可能喜欢的功能,例如文章或食谱等。
2条答案
按热度按时间0g0grzrc1#
虽然我喜欢简洁明了的内容,但我还是建议将commentlikes、postlikes和这样的表彼此分开。这样,查看您的数据库的人可以看到comments表并找到commentlikes表,并且可以很容易地理解正在发生的事情。
当连接表时,在查询中连接comments表和commentlikes在思想上更容易。
我想说,你可以同样容易地从单一的likes表和单独的likes表中获取数据。例如,如果您想找出哪条评论最受欢迎,请使用简明表格:
如果是分开的,你会写:
单独的表允许您定义外键关系。外键允许引用完整性,并有一定的性能开销。您必须决定开销是否足够大,以避免影响引用完整性(或添加额外代码以补偿数据库中的ri权限)。
如果表是分开的,您还可以以可读的方式在评论、帖子等之间更改like的行为。例如,如果您希望在评论中使用不同类型的likes(例如heart、恭喜、不喜欢等),而不是post,那么单独的表可以允许这种灵活性。你也可以用一张table做同样的事情。如果表格分开,可读性会更好。
如果你在评论和帖子上得到大量的赞,那么赞表会比赞表分开时变大的更快。
您可以从一个简洁的表开始,在适当的时候将其拆分,也可以从不同的表开始,稍后再将其合并。
j7dteeu82#
你的方法很好。您要做的是——不幸的是——在sql中并不简单。理想情况下,您希望在
target_id
以及它引用的表。以你的结构,这是不可能的。然而,您的方法确实具有简洁性的优点——无论是在表定义中还是在底层的表布局中。代价是无法声明外键关系。
编辑:
如果有一个简单的选择,我会建议。您可以为每个外键关系设置一个单独的列,但这不仅会占用空间,而且会使添加新关系变得困难。您可以为外键生成列,但这相当麻烦,应该为外键关系持久化这些列。
没有最佳的解决方案,所以你的版本是好的。其他解决方案也很好,这取决于您需要解决方案做什么。