为了账号安全,请及时绑定邮箱和手机立即绑定

在数据库中实现评论和喜欢

/ 猿问

在数据库中实现评论和喜欢

我是一名软件开发人员。我喜欢编码,但我讨厌数据库...目前,我正在创建一个网站,允许用户将实体标记为喜欢(如FB),标记和评论。


我被困在数据库表设计上来处理这个功能。解决方案是微不足道的,如果我们只能为一种类型的东西(例如照片)做到这一点。但我需要为5种不同的东西启用它(现在,但我也假设随着整个服务的增长,这个数字会增长)。


我在这里发现了一些类似的问题,但没有一个问题得到满意的答案,所以我再次提出这个问题。


问题是,如何正确,高效和弹性地设计数据库,以便它可以存储不同表的注释,喜欢不同的表和标签。一些设计模式作为答案将是最好的;)


详细描述:我有一个表 User与一些用户数据,以及3个表:Photo用照片,Articles用文章,Places用的地方。我想启用任何已登录的用户:


评论这3个表中的任何一个


将其中任何一个标记为喜欢


使用某个标记标记其中任何一个


我还想计算每个元素的喜欢次数以及使用特定标记的次数。 



1 日的做法:


a)对于标签,我将创建一个表 Tag [TagId, tagName, tagCounter],然后我会创造很多一对多的关系表为:Photo_has_tags,Place_has_tag,Article_has_tag。


b)同样重要的评论。


三)我将创建一个表 LikedPhotos [idUser, idPhoto],LikedArticles[idUser, idArticle],LikedPlace [idUser, idPlace]。喜欢的数量将通过查询计算(我认为这是坏的)。和...


我真的不喜欢这个设计的最后一部分,它对我来说很难闻;)



2 次的方法:


我将创建一个表ElementType [idType, TypeName == some table name],该表将由管理员(我)填充,其中包含可以被喜欢,评论或标记的表的名称。然后我将创建表:


a)LikedElement [idLike, idUser, idElementType, idLikedElement]和注释和标签相同,每个都有适当的列。现在,当我想拍照时,我会插入:


typeId = SELECT id FROM ElementType WHERE TypeName == 'Photo'

INSERT (user id, typeId, photoId)

和地方:


typeId = SELECT id FROM ElementType WHERE TypeName == 'Place'

INSERT (user id, typeId, placeId)

......等等......我认为第二种方法更好,但我觉得这个设计中也缺少一些东西......


最后,我还想知道哪个最好的地方存放计数器元素被喜欢多少次。我只能想到两种方式:


在element(Photo/Article/Place)表中

通过select count()。

我希望我对这个问题的解释现在更彻底。


查看完整描述

3 回答

?
开满天机

最具扩展性的解决方案是只有一个“基础”表(连接到“喜欢”,标签和注释),并“继承”其中的所有其他表。添加一种新的实体只需添加一个新的“继承”表 - 然后它会自动插入整个like / tag / comment机器。

实体关系术语是“类别”(参见 ERwin方法指南,部分:“子类型关系”)。类别符号是:

//img1.mukewang.com/5d81a0210001955400630027.jpg

假设用户可以喜欢多个实体,同一个标签可以用于多个实体,但注释是特定于实体的,您的模型可能如下所示:

//img.mukewang.com/5d81a02300013ed807250550.jpg


顺便说一下,实施“ER类别”大致有3种方式:

  • 所有类型都在一个表中。

  • 所有具体类型在单独的表中。

  • 所有具体和抽象类型在单独的表中。

除非您有非常严格的性能要求,否则第三种方法可能是最好的(意味着物理表与上图中的实体1:1匹配)。


查看完整回答
反对 回复 2019-09-18
?
天天世纪

既然你“讨厌”数据库,你为什么要尝试实现一个?相反,向喜欢和呼吸这些东西的人寻求帮助。

否则,学会爱你的数据库。精心设计的数据库简化了编程,设计网站并平滑其持续运营。即使是经验丰富的d / b设计师也不会有完整和完美的远见:随着使用模式的出现或需求的变化,将需要一些架构变化。

如果这是一个单人项目,则使用存储过程将数据库接口编程为简单操作:add_user,update_user,add_comment,add_like,upload_photo,list_comments等。不要将模式嵌入到一行代码中。通过这种方式,可以在不影响任何代码的情况下更改数据库模式:只有存储过程应该知道模式。

您可能需要多次重构架构。这很正常。不要担心第一次完美。只需使其功能足以原型化初始设计。如果您有足够的时间,请使用它,然后删除架构并再次执行。它总是更好的第二次。


查看完整回答
反对 回复 2019-09-18
?
陪伴而非守候

这是一个普遍的想法请不要太注意字段名称样式,但更多的是关系和结构

//img3.mukewang.com/5d81a0390001accc07260480.jpg

这个伪代码将获得照片的所有注释ID 5

SELECT * FROM actions 

WHERE actions.id_Stuff = 5 

AND actions.typeStuff =“photo” 

AND actions.typeAction =“comment”


这个伪代码将获得喜欢ID为5的照片的所有喜欢或用户

(您可以使用count()来获得喜欢的数量)


SELECT * FROM actions  

WHERE actions.id_Stuff = 5  

AND actions.typeStuff="photo"  

AND actions.typeAction = "like"  


查看完整回答
反对 回复 2019-09-18

添加回答

回复

举报

0/150
提交
取消
意见反馈 邀请有奖 帮助中心 APP下载
官方微信