当前位置:  开发笔记 > 编程语言 > 正文

SQL查询 - 如何有效地获取非读取消息

如何解决《SQL查询-如何有效地获取非读取消息》经验,为你挑选了1个好方法。

如何最好地收集给定用户未读取的消息?

现有表格

Message table
----------------------------------
id    title    body    sentAt

User table
----------------------------------
id    username

Read Messages table
----------------------------------
user_id    message_id

我在想类似的东西

select 
  m.id, m.title, m.sentAt, u.username
from 
  message m,
  [user] u
where 
  u.id = 1 and -- @userId parameter
  m.id not in 
    (select r.message_id from read_messages r where r.user_id = u.id)

不幸的是,我不太了解执行计划./亚当



1> Henrik Paul..:

建议另一种方法:

我之前在工作中遇到了完全相同的问题.我花了一周的时间试图找到最好的方法来做到这一点.我最终创建了一个连接表,就像您所做的那样,但该表仅包含未读消息,而不是跟踪读取消息.

因为

    现状是"每个人都阅读了他们所有的消息".

    获取未读消息(或其计数)应该尽可能快.

    现状应该是系统中最不紧张的状态.

现在,如果我要跟踪每个人都读过的所有消息,那么数据库中的混乱就会迅速增长(用户*消息行),在更小的应用程序中容易导致成千上万行的"自重".如果消息的生命周期是无限期的,那么这个问题就会被夸大 - 您可以跟踪多年前的消息状态.

如果跟踪反向,则"未读消息"表仅包含少量行,并且对于用户读取的每条消息,它们会减少.此外,获取未读消息的数量就像" SELECT COUNT(*) FROM unread WHERE user = foo" 一样简单.

作为一切,这是一个权衡.虽然阅读速度与计算速度一样快,但写作是一件苦差事.对于每个书面消息,您需要在此连接表中插入一个条目.此外,如果多个人可以阅读相同的邮件,则需要为每个收件人插入一行.如果收件人是隐式的(例如,仅给出用户组的名称,或者甚至使用诸如"有权访问此事物的任何人"的标准),则创建新消息变得更加复杂.

但我觉得这是一个公平的妥协.

YMMV,HTH.

推荐阅读
ERIK又
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有