如何在数据库中存储一个或多个复选框值？
正如这个问题肯定会揭示的那样，我对数据库设计相对较新。请原谅我的理解不够。
我想在数据库中存储如下所示的值（来自 Google 日历的示例）：
最好的方法是什么要这样做吗？这是一个数据库字段还是多个？
如果是前者，这是否违反规范化规则？
谢谢！
As this question is sure to reveal, I'm relatively new to database design. Please pardon my lack of understanding.
I want to store values like the following (example from Google calendar) in a database:
What's the best way to do this? Would this be one database field or several?
If the former, does this disobey normalization rules?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我建议您创建一个多对多关系，您可以以更逻辑的方式（规范化）实现分离列...对于上面的示例：
您应该有一个名为“schedules”的表（或任何对您有意义的表） ，另一个类似“repeat_on”的东西和第三个名为“days”的表（这里有周一至周日及其 ID）。在中间的表（repeat_on）中，您应该创建外键（对于其他 2 个表：schedule_id 和 day_id）来发挥作用。
这样你就可以组合任何你想要的东西，例如：
这意味着你必须在周一、周三和周日做同样的事情。
I suggest you to create a relation many-many, you can achive that separating the columns in more logical way (normalization) ... for the example above:
You should have a table called "schedules"(or whatever make sense to you), another something like "repeat_on" and a third table called "days"(here you have monday-sunday with their IDs). In the table of the middle(repeat_on) you should create foreign keys(for the other 2 tables: schedule_id and day_id) to do the magic.
This way you can combine whatever you want, for example:
Meaning that you have to do the same on monday, wednesday and sunday.
IMO，标准化是一门艺术。不过，我通常会将像您的示例这样的字段保存在一张表中，因为我们的时间永远不会超过 7 天。但是，如果有任何增长的机会，我会将其放在单独的表中。
IMO, normalization is an art. However, I usually take fields like your example and keep them in one table as we will never have more than 7 days. However, if there is any chance of growth I would put it in a separate table.
如果选项是互斥的，那么您可以使用一个字段来存储选项。理想情况下，为字段设置约束，以便仅存储允许的值。
如果可以选择多个选项，则每个选项应有一个字段，其值为“y”和“n”（或“t”/“f”表示真/假）。同样，您应该添加一个约束以仅允许这些值。如果您的 DBMS 支持，请使用 BIT 数据类型，它只允许 1 和 0。
If the options are mutually exclusive, then you can use one field to store the choice. Ideally set up constraints for the field such that only the allowed values can be stored.
If more than one option can be chosen, you should have one field per option, with values 'y' and 'n' (or 't'/'f' for true/false). Again, you should add a constraint to only allow these values. If you DBMS supports it, use a BIT datatype, which only allows 1 and 0.
对于您的示例来说，这可能有些夸张，但您可能需要查看以下文章：
http://martinfowler。 com/apsupp/recurring.pdf
我知道这是一个间接答案，但阅读起来也没什么坏处。
This may be overblown for your example, but you may want to look at the following article:
http://martinfowler.com/apsupp/recurring.pdf
I know this is an indirect answer but couldn't hurt to read.
像一周中的几天这样的事情很棘手。 PachinSV 和达斯汀·莱恩 (Dustin Laine) 都提出了很好的观点。如果您有一个可供选择的事物列表，那么使用一个代码表来列出这些事物，并使用一个交集表来说明选择哪些事物是一个很好的基本设计。
一周中的几天很棘手的原因是域（即日期列表）非常小，并且域永远不会扩展。此外，交集表方法的优点之一是您可以对星期三发生的所有事情运行查询（例如）。当您的代码表类似于博客文章的类别标签时，这非常有用，因为要求查看带有“How-To”标签的所有内容是一个合理的问题。对于一周中的几天重复的情况，说“向我显示周三重复的所有内容”是否有任何实际的商业意义？我不这么认为。当然，您会查询日期和日期范围，但是一周中的几天，并且仅在重复的上下文中？我想不出这样做的实际理由。
因此，有一个论点认为一周中的日子是属性而不是独立实体，因此表上有七个位标志仍然是 3NF。
Something like days of the week is tricky. PachinSV and Dustin Laine both make good points. If you have a list of things to choose from, having a code table to list the things and an intersection table to say which ones are chosen is a good basic design.
The reason days of the week are tricky is that the domain (i.e. list of days) is pretty small and there is no way the domain will ever expand. Also, one of the advantages of the intersection table approach is that you can run a query against everything that happens on a Wednesday (for example). This is great when your code table is something like category tags for blog articles, since asking to see everything with the tag "How-To" is a reasonable question. For the case of days of the week recurrence, does it make any actual business sense to say show me everything that recurs on Wednesdays? I don't think so. For sure you'll query on dates and date ranges, but days of the week, and only in the context of recurrence? I can't think of a practical reason to do that.
Therefore, there is an argument to be made that the days of the week are attributes and not independent entities so having seven bit flags on your table is still 3NF.