关于mysql：在数据库中实现注释和喜欢


Implementing Comments and Likes in database

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

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

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

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

详细说明：
我有一个带有一些用户数据的表User，还有3个表：带有照片的Photo，带有文章的Articles，带有地点的Places。我想启用任何已登录的用户：

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

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

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

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


第一种方法：

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

b)同样重要的评论。

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

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



第二种方法：

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

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

1
2
typeId = SELECT id FROM ElementType WHERE TypeName == 'Photo'
INSERT (user id, typeId, photoId)

和地方：

1
2
typeId = SELECT id FROM ElementType WHERE TypeName == 'Place'
INSERT (user id, typeId, placeId)

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

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

  • 在元素(Photo/Article/Place)表中
  • 通过select count()。

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

    相关讨论

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

    实体关系术语是"类别"(参见ERwin方法指南，部分："子类型关系")。类别符号是：

    Category

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

    ER Diagram

    顺便说一下，实施"ER类别"大致有3种方式：

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

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

    相关讨论

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

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

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

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

    相关讨论

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

    enter image description here

    这个伪代码将获得ID为5的所有照片评论
    SELECT * FROM actions
    WHERE actions.id_Stuff = 5
    AND actions.typeStuff ="photo"
    AND actions.typeAction ="comment"

    这个伪代码将获得喜欢ID为5的照片的所有喜欢或用户
    (你可以使用count()来获得喜欢的数量)

    1
    2
    3
    4
    SELECT * FROM actions  
    WHERE actions.id_Stuff = 5  
    AND actions.typeStuff="photo"  
    AND actions.typeAction ="like"
    相关讨论

    绝对采用第二种方法，你有一个表并存储每行的元素类型，它会给你更多的灵活性。基本上，当逻辑上可以用更少的表完成某些事情时，使用更少的表几乎总是更好。我现在想到的关于你的特定情况的一个优点，考虑你想要删除某个用户的所有喜欢的元素，你需要为你的第一种方法为每种元素类型发出一个查询，但是使用第二种方法可以完成只有一个查询或考虑何时想要添加新的元素类型，第一种方法涉及为每种新类型创建一个新表，但使用第二种方法则不应该做任何事情......

    查看您将需要的访问模式。他们中的任何一个似乎特别困难或低效我的一个设计选择或另一个？

    如果不喜欢需要较少表格的那个

    在这种情况下：

  • 添加注释：您要么选择一个特定的多/多个表，要么插入一个具有已知特定标识符的公共表中，我认为客户端代码在第二种情况下会稍微简单一些。
  • 查找项目的注释：这里似乎使用公共表稍微容易一些 - 我们只有一个按实体类型参数化的查询
  • 查找一个人关于某种事情的评论：两种情况下的简单查询
  • 查找一个人关于所有事情的所有评论：无论哪种方式，这似乎都不太可能。

    • 我认为你的"歧视"方法，选项2，在某些情况下会产生更简单的查询，而在其他情况下看起来并不差，所以我会选择它。

    据我所理解。需要几张桌子。他们之间有很多关系。

    • 使用标识字段存储名称，姓氏，出生日期等用户数据的表。
    • 存储数据类型的表。这些类型可能是照片，分享，链接。每种类型都必须有一个唯一的表。因此，它们各自的表与该表之间存在关系。
    • 每种不同的数据类型都有其表。例如，状态更新，照片，链接。
    • 最后一个表用于存储id，用户id，数据类型和数据id的多对多关系。
    相关讨论

    考虑使用每个实体的表来进行注释等。更多表 - 更好的分片和缩放。对于我所知道的所有框架，控制许多类似的表并不是一个问题。

    有一天，您需要优化来自此类结构的读取。您可以轻松地在基础表上创建agragating表，并在写入时丢失一些。

    一天有字典的大表可能会变得无法控制。

    相关讨论