在数据库中保存琐碎用户状态(例如取消欢迎消息)的最佳方法是什么?
我应该为每个新状态使用(创建)一列吗?或者一个带有一堆逗号分隔状态的字段(或者 json obj)?欢迎任何建议。
更新
首先让我感谢您的回答。我只是想弄清楚,我看到了什么选项:
- 为用户行中的每个状态放置一列(初始计划)/可能会因为很多状态而变得混乱(将来)
- 在用户中放置一个包含 json/xml 数据的列row / 易于维护(无需更改数据库),但感觉不对
- 有一个专用的状态表(thx lhiles )/ 听起来很酷,这张桌子会是什么样子?
我正在寻找不同实现的优点/缺点。再次:谢谢!
Should I use (create) a column for every new state? Or one field with a bunch of comma separated states (alternatively a json obj)? Any suggestions welcome.
UPDATE
First let me day thanks for the answers. I just want to clear up, what options I see:
- Put a column for every state in the user row (initial plan) / Can get messy with lots of states (in the future)
- Put one column with json/xml data in the user row / Easy to maintain (no db change required), but doesn't feel right
- Have a dedicated states table (thx lhiles)/ Sounds cool, how would this table look like?
I'm looking for pros/cons of the different implementations. Again: Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
为每个州创建一列。这是正确的数据标准化。
通过每个状态的一列,您可以根据当前操作的需要检索尽可能少或任意多的状态。
返回的所有状态将包含在一行中,并且每列都已命名。这使得引用每个状态值变得非常容易。
它允许您根据需要轻松地向每个状态添加约束。 (状态 X 只能包含“1”或“2”。)
它允许您轻松查询跨用户的状态。 (有多少用户将状态值设置为“X”?)
Create a column for each state. This is proper data normalization.
With a column for each state you can retrieve as few or as many states as needed for the current operation.
All of the states returned will be contained in a single row with each column named. This makes referencing each state value very easy.
It allows you to easily add constraints to each state as needed. (State X can only contain '1' or '2'.)
It allows you to easily query states across users. (How many users have set a state value to 'X'?)
我的首选方法是为用户设置创建一个专用表。每个状态/设置对应于该表中的一列。随着项目的增长,可以添加额外的列,而不会扰乱应用程序的核心数据。
另一种方法是,如果您觉得设置太多而无法为每列分配 1 个设置,则可以将设置存储为 SQL 中的 XML(或您提到的 json)数据。这将允许您导出所需的任何类型的状态格式,但是,它会给程序员带来更多的工作来解析、验证和保留这些设置。
My preferred method is to create a dedicated table for user settings. Each state/setting corresponds to a column within that table. As your project grows additional columns can be added without cluttering your apps core data.
Another route, if you feel that there will be too many settings to devote 1 setting per column, would be to store the settings as XML (or json as you mentioned) data within SQL. This would allow you to derive any type of state format you wanted, however, it puts more work on the programmer to parse, validate, and persist those settings.
如果状态是互斥的,您可以使用
ENUM
保存状态;例如,人是男性或女性。或者如果状态可以共存,则使用
SET
;例如,人是(AA 和 CA 和 SOsA*)的成员使用两者的示例表:
如果您使用
ENUM
,我个人建议您设置一个除null 之外的显式默认值
,因为大多数时候必须做出选择。链接: http://dev.mysql.com/doc/refman /5.1/en/constraint-enum.html
*
(stackoverflow 受害者匿名)You can save state using an
ENUM
if the states are mutually exclusive; e.g. person is male or female.Or using a
SET
if states can co-exist; e.g. person is a member of (AA and CA and SOsA*)A sample table using both:
If you're using an
ENUM
I personally would recommend you set an explicit default value other thannull
, because most of the time a choice must be made.Link: http://dev.mysql.com/doc/refman/5.1/en/constraint-enum.html
*
(stackoverflow sufferers anonymous)我真的不会像大多数其他人所建议的那样,为每个设置设置一列。我会每行进行一个设置,因为这不需要每次添加设置时都进行架构更改(包括升级脚本)。
更好的是,编写一些反射代码在应用程序启动时运行,该代码将查看枚举上的条目并自动在数据库中创建一条记录(使用您在每个枚举值的自定义属性中指定的一些默认值)。
我最近做了类似上面指出的事情。现在要添加新设置,我将一个条目添加到枚举中,仅此而已。新设置大约需要 10 秒。
我可能会将我的代码放在 CodeProject 上,它使开发变得容易。
I really wouldn't do this with a column per setting, as most of the other people are suggesting. I'd do a setting per row because this doesn't require schema changes (including upgrade scripts) every time you add a setting.
Better yet, write some reflection code to run on app startup that'll look at the entries on an enum and automatically create a record in the database (with some default value that you specify in a custom attribute on each enum value).
I recently did something like I'm indicating above. Now to add a new setting, I add an entry to an enum and that's it. New settings take about 10 seconds.
I may put my code up on CodeProject, it has has made development easy.