0

我正在尝试添加一个操作表，但我目前对于如何解决这个问题存在分歧。

在我详细介绍之前。

我们的会员可以在我们的网站上执行不同的操作

  • 添加图像
  • 更新图像
  • 评价图像
  • 在图片上发表评论
  • 添加博客文章
  • 更新博客文章
  • 评论博客文章
  • 等等等等

操作表允许我们的用户“观看”其他成员的活动，如果他们想将他们添加到他们的观察列表中。

我目前创建了一个名为member_actions的表，其中包含以下列

[UserID] [actionDate] [actionType] [refID]

[refID] 可以是对数据库中的图像 ID 或博文 ID 的引用，也可以是另一个可操作表的 id 列（例如事件）

[actionType] 是一个 Enum 列，具有操作名称，例如 (imgAdd,imgUpdate,blogAdd,blogUpdate, etc...)

[actionDate] 将决定每 90 天删除哪些记录...因此我们不会永远保留这些操作

我提出的当前 mysql 查询是

SELECT act.*, 
        img.Title, img.FileName, img.Rating, img.isSafe, img.allowComment AS allowimgComment,
        blog.postTitle, blog.firstImageSRC AS blogImg, blog.allowComments AS allowBlogComment,
        event.Subject, event.image AS eventImg, event.stimgs, event.ends,
        imgrate.Rating
    FROM member_action act
    LEFT JOIN member_img img ON (act.actionType="imgAdd" OR act.actionType="imgUpdate")
                     AND img.imgID=act.refID AND img.isActive AND img.isReady
    LEFT JOIN member_blogpost blog ON (act.actionType="blogAdd" OR act.actionType="blogUpdate")
                    AND blog.id=act.refID AND blog.isPublished AND blog.isPublic
    LEFT JOIN member_event event ON (act.actionType="eventAdd" OR act.actionType="eventUpdate")
                    AND event.id=act.refID AND event.isPublished
    LEFT JOIN img_rating imgrate ON act.actionType="imgRate" AND imgrate.UserID=act.UserID AND imgrate.imgID=act.refID
    LEFT JOIN member_favorite imgfav ON act.actionType="imgFavorite" AND imgfav.UserID=act.UserID AND imgfav.imgID=act.refID
    LEFT JOIN img_comment imgcomm ON (act.actionType="imgComment" OR act.actionType="imgCommentReply") AND imgcomm.imgID=act.refID
    LEFT JOIN blogpost_comment blogcomm ON (act.actionType="blogComment" OR act.actionType="blogCommentReply") AND blogcomm.blogPostID=act.refID
    ORDER BY act.actionDate DESC
    LIMIT XXXXX,20

好的，基本上，考虑到我将每周删除超过 90 天左右的操作...使用此查询来显示成员操作历史记录是否有意义？

或者我应该在member_actions表中添加一个名为 [actionData] 的新文本列，我可以在其中以 json 或 xml 格式存储一些详细信息，以便快速查询 member_action 表。

它增加了表的大小并降低了查询的复杂性，但该表将定期从旧条目中清除。

假设最终我们将拥有不超过 100k 的成员，所以我会担心 member_action 表的表大小，它的文本 [actionData] 列将包含一些特定的细节。

我倾向于 [actionData] 模型，但任何建议或考虑将不胜感激。

另一个考虑因素是 img 或 blog 的表条目可能会被删除......所以我可以采取行动但没有参考记录......这确实会增加问题。

提前致谢

4

2 回答 2

1

我会警惕这种方法 - 当您添加要监视连接的各种操作时，连接将继续增长（以及 select 语句中的稀疏额外列）。

我不认为在这个表中有几个额外的列会那么可怕——而且这个查询听起来会相当频繁地运行，所以让它变得高效似乎是个好主意。

于 2013-01-03T22:28:00.107 回答
1

因为您正在处理用户界面问题，所以性能是关键。所有的连接都需要时间，即使有索引。而且，查询数据库可能会锁定所有表（或索引）中的记录，这会减慢插入速度。

因此，我倾向于通过维护记录中的文本来对数据进行非规范化。

但是，一个关键的考虑因素是文本是否可以在事后更新。也就是说，您将在创建数据时加载数据。那么它可以改变吗？根据更改（可能涉及触发器和存储过程）维护数据的问题可能会带来很多额外的复杂性。

如果数据是静态的，这不是问题。至于桌子的大小，我认为您不必担心太多。数据库旨在管理内存。它在页面缓存中维护表，该表应包含当前活动成员的页面。您总是可以增加内存大小，尤其是对于 100,000 个用户，这在当今服务器的范围内。

于 2013-01-03T22:30:45.893 回答