我要将用户Likes
存储到数据库中。但我不确定这两种方法中哪一种更好:
在我的情况下,用户可以点Posts
,Comments
和Groups
。 Facebook之类的东西。
假设有1000万个喜欢:Posts
,Comments
和Groups
方法A:
创建 Like
表,并在其中添加LikeType
字段:
+--------+----------+--------+
| likeID | LikeType | userID |
+--------+----------+--------+
| 1 | 1 | 1 | // User 1 liked a post
+--------+----------+--------+
| 2 | 2 | 1 | // User 1 liked a comment
+--------+----------+--------+
| 3 | 3 | 1 | // User 1 liked a group
LikeType
包括:1,2,3
1 =帖子,2 =评论,3 =组
方法B:
为帖子,评论和群组中的每一个创建三个分隔的表。
,
因为有太多喜欢,需要一个额外的条件(Where status = 1, or 2, or 3
)来获得帖子,评论或群组喜欢,哪种方法更好?
users
uid // PK
---------------------------------------
itemTypes
typeID // PK
typeText // comments, groups, posts
---------------------------------------
--------------------------------------- +
posts |
id // PK |
typeID // 1 |
... |
--------------------------------------- +
comments |
id // PK |
typeID // 2 |
... |
--------------------------------------- + Items
groups |
id // PK |
typeID // 3 |
... |
--------------------------------------- +
photos |
id // PK |
typeID // 4 |
... |
--------------------------------------- +
---------------------------------------
likes
uid // FK to user id
itemid // FK to posts, groups, photos, comments id
itemType // FK to itemsTypes.typeID
// select post #50 likes
SELECT count(*) FROM likes WHERE itemid = 50 and itemType = 1
// select comment #50 of user #2
SELECT * FROM likes WHERE itemid = 50 and uid = 2 and itemType = 2
这是一个很好的架构吗?
答案 0 :(得分:1)
我不喜欢你的任何一种方法。我会更加规范化。我会有一个表项目类型,如评论,组,帖子等。然后我会有一个项目表。它将具有作为PK的ItemId和对项类型的FK引用。还会有一个用户表。最后,喜欢的表将是项目和用户之间的多对多关系。
答案 1 :(得分:1)
正如Jan Doggen所说,你正在做的信息是一个重要的考虑因素。特别是,如果您希望能够提出“给定用户喜欢什么”这样的问题,那么您将从一个表中包含所有数据中受益 - 否则,您必须有三个单独的查询来回答那个问题。
对于“哪些人喜欢给定的东西”这个问题的情况,如果你的表被正确索引(在likeID /上有索引),单表模型和多表模型之间的性能差异应该相对较小likeType,在这种情况下)。多表模型将使您的应用程序逻辑变得更加复杂,并且在您希望添加用户可能喜欢的其他内容时将来更难扩展。