具有相同值但处于不同状态/问题的单个或多个 ID
我有一个查找值“未读”。这里使用的是： 邮件可以是已读或未读。 （所以我的 ID 10 = 已读，ID 11 = 未读）。现在在 UI 中我有显示过滤器，我可以通过预定义的过滤器对消息进行排序，其中之一是“未读”所以问题是：这两种情况下的 ID 都是 11 还是我为未读创建两个单独的值 - 一个一个用于消息状态，一个用于显示排序？
该数据的用途有 2 倍：
1）根据FK查找ID引用其主要动作
2) 报告：如果我想查看有多少用户使用未读过滤器对未读邮件进行排序，在这种情况下我可以轻松获得该数字 - 通过使用两个 ID（每个问题一个（消息状态和显示排序）或仅一个 ID） ？
I have a lookup value "Unread". It is used here:
Mail can be read or unread. (So i have ID 10 = read and ID 11 = unread). Now in the UI I have display filters where i can sort message by predefined filters, one of these is 'Unread' So the question is: Are the IDs in both cases going to be 11 or do i create two separate values for Unread - one for the message state and one for the display sort?
The use of this data is 2 folds:
1) Reference its main action based on the FK lookup ID
2) Reporting: If i want to see how many users sorted using Unread filter for Unread mail, in which case can i get that number easily - by using two IDs (one for each question (message state and display sort) or one ID only?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
已读/未读状态值是消息项的属性，而不是 GUI 或用户的属性。用户选择的过滤器状态是用户的属性，而不是消息的属性。
如果您认为在这两个相似但独立的代码列中使用相同的值是有意义的，那么就可以了。
您需要将消息状态存储为消息上的一列（除非您想要跟踪消息状态的历史记录，在这种情况下，它必须进入消息的子表）。您需要在用户表中存储每个用户的当前过滤器选择状态。我无法想象您为什么要对其进行历史记录，因此用户表上的一列就可以解决问题。
如果消息表中的未读内容是“11”，并且用户表中的未读内容也是“11”，那么这很好，但这是巧合，您需要小心地在代码中对此做出任何假设。当您开始添加其他过滤器组合时，整个方案可能会崩溃，除非您致力于在用户/GUI 过滤器选择表中拥有匹配的属性对，并且任何消息属性与您的过滤器选项一致。
The status value of read/unread is a property of the message item, not of the GUI or the user. The filter state selected by the user is a property of the user, not the message.
If it makes sense to you to have the same values used in these two similar, but independent code columns, then that is fine.
You need to store the message state as a column on the message (unless you want to track the history of message state, in which case it has to go into a child table of the message). You need to store the current filter selection state for each user on your user table. I can't imagine why you'd want to historize that so a single column on your user table should do the trick.
If unread in the message table is "11" and unread in the user table is also "11" then that's fine, but it's coincidental and you want to be careful about making any assumptions in your code about this. When you start adding in other filter combinations the whole scheme could come crashing down on you unless you're committed to having matched pairs of attributes in your user/gui filter selection table and whatever message attributes line up with your filter options.