MySQL 事务
我目前正在创建一个消息系统,我想知道我是否应该使用事务(据我了解其目的)。
我目前有三个表:
对话:主题等
messages :消息(对话表的 FK 约束)
参与者:对话中人员的用户 ID
假设用户必须是对话的参与者才能阅读对话。在一个页面中,我将执行两项查询,一项针对对话数据,一项针对消息。这可能是我偏执,但我如何确保用户参与(事物的整体状态)在这两个查询之间不会改变?交易是关键吗?我会遇到任何性能问题吗?
(通过两个查询的 join 检查参与情况)
提前致谢。
I'm currently creating a messaging system and I was wondering if I should be using transactions (from what I understand their purpose is).
I currently have three tables:
conversations : subject, etc
messages : messages (FK constraint to conversations table)
participants : user ids of people in conversation
Lets say that an user has to be a participant of a conversation to read it. In a page, I'd perform two queries, one for the conversation data and one for the messages. It could be me being paranoid but how can I ensure that an users participation (the overall state of things) doesn't change between these two queries? Would a transaction be the key? Would I encounter any performance problems?
(participation is checked via join on both queries)
Thanks in advance.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
你为什么不像穆建议的那样呢?只需添加一点扭曲...
我错过了什么吗?
事务通常用于确保写入操作(而不是读取)记录之间的一致性。
Why don't you something like Mu is suggesting? Just add a little twist...
Am I missing something?
Transactions are usually used to ensure consistency between records on writing operations, not reading.
交易肯定会对您的情况有所帮助。您可能需要来自数据库约束的一些额外帮助。
Transactions should certainly help in your situation. You might need some extra help from the database constraints hough.
如果您担心某人可能会在两个查询之间离开对话(通过单独的流程或请求),那么事务就不是您想要的。您想要做的是将联接添加到“对话”表中,以过滤掉不再参与对话的人员,如下所示:
其中
$current_user
是有问题的用户。然后,如果$current_user
不再在会话中,则连接中不会出现任何行,也不会选择任何内容。If you're worried that a person could leave the conversation (through a separate process or request) between your two queries then a transaction isn't what you want. What you want to do is add a join to the "conversations" table to filter out people that are no longer in the conversation, something sort of like this:
Where
$current_user
is the user in question. Then, if$current_user
is no longer in the conversation, no rows will come out of the join and nothing will be selected.