如何使用位掩码存储工作计划信息？
创建一个非常简单的日程安排应用程序
我要求用户告诉我他们工作哪一天，以及在给定的一天他们是早上、午餐还是晚上工作，
因此，对于给定的用户，她的数据可能是以下之一或全部对于以下矩阵中的点，
morning lunch evening
mon
tue
wed
thr
fri
sat
sun
我需要能够快速检索此信息，以便我可以提醒用户该去上班了。我将会有很多用户。
我不在乎具体的日期或时间。只是离散的第 1 天到第 7 天以及每天的 3 个时段。当然，有很多种可能的组合。
我正在考虑如何存储这些信息。我想知道位掩码是否合适/可行/“处理此类事情的方法”？你会如何处理这个问题？
谢谢！
creating a very simple scheduling app
I am asking the user to tell me what day(s) they work, and whether on a given day they work morning, lunch, or evening
so, for a given user her data could be one or all of the points in the following matrix
morning lunch evening
mon
tue
wed
thr
fri
sat
sun
I need to quickly be able to retrieve this information so that I can alert the user that it's time to go to work. I will have many users.
I don't care about specific dates, or time. just the discrete days 1 through 7 and the 3 slots within each day. Certainly, there are many possible combinations.
I am considering how to store this information. And I am wondering if a bitmask is appropriate / feasible / the 'way to go with something like this' ? How would you approach this?
thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
虽然位掩码肯定会起作用（使用 7 天 X 3 个班次 = 21 位），但我对这些东西的经验是它们总是需要修改。也就是说，增加夜班，或者以其他方式改变班次。
鉴于此，我建议在您的应用程序中构建一些灵活性。将位掩码的想法与定义位所代表内容的表相结合。这样您就可以根据需要重新定义和修改。如果添加班次，只需在定义表中添加一条记录并更新每个员工的掩码即可。
While a bitmask will definitely work (employing 7 days X 3 shifts = 21 bits), my experience with these things is they always need modification. That is, a night shift is added, or shifts are otherwise changed.
Given that, I'd suggest building some flexibility into your app. Combine the bitmask idea with a table that defines what the bits represent. That way you can redefine and modify as you please. If you add a shift, just add a record to the definition table and update each employee's mask.
回答你的第二个问题：除非你有数百万行，否则位掩码不会带来巨大的性能优势（你的瓶颈仍然是网络 I/O），并且可能是过早的优化。也就是说，您将能够将所有用户选项存储在单个 32 位整数中。
To answer your second question: unless you have millions of rows, a bitmask is not going to be a huge performance advantage (your bottleneck will still be network I/O) and probably a premature optimization. That said, you will be able to store all of the user's options in a single 32 bit integer.
不要为位掩码烦恼。现在做一些简单的事情（比如规范化的数据库模式！），并在稍后开始衡量问题时优化性能。
Don't bother with a bitmask. Do something simple now (like perhaps a normalized DB schema!), and optimize for performance later if you start measuring problems.
如果他们每天只能选择一个选项，则可以将数据打包成 16 位 int 的 14 位。或者，如果他们每天可以选择多个选项，您可以将其打包到 32 位 int 的 21 位中。
If they can only choose one option per day, you can pack the data into 14 bits of a 16-bit int. Or if they can choose multiple options per day, you could pack it into 21 bits of a 32-bit int.