您如何处理需要持久化的一次性数据？
最近，我被要求为一个网站的管理员添加一些东西，他可以在其中“展示”一些东西。
对于本次讨论，我们假设这是一篇“专题文章”。
所以很自然地，我们已经有了一个“文章”的数据库模型，它有大约 20 列，所以我真的不想再让它变得臃肿了。
我的选择：
添加一个“特色”布尔值（或整数），并意识到在任何给定时间只有一件事会被推荐
创建一个新模型来保存这个和任何其他可能弹出的特征蠕变项目。
创建我接受你的建议！ ;)
在这种情况下你会做什么？ 我时不时地会遇到这种情况，我只是讨厌在某件事上再增加一个专栏。 该信息确实需要保留。
Recently I've been requested to add on something for the administrator of a site where he can 'feature' something.
For this discussion let's say it's a 'featured article'.
So naturally we already have a database model of 'articles' and it has ~20 columns as it is so I really do not feel like bloating it anymore than it already is.
My options:
Tack on a 'featured' bool (or int) and realize that only one thing will be featured at any given time
Create a new model to hold this and any other feature-creep items that might pop up.
I take your suggestions! ;)
What do you do in this instance? I come across this every now and then and I just hate having to tack on one more column to something. This information DOES need to be persisted.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我可能只是添加一个简单的两列表，它基本上是一个键值存储。 然后添加一个新列，其中包含诸如
(featured_article_id, 45)之类的值或第一个精选 ID 的值。编辑：正如 rmeador 在评论中指出的那样，应该注意的是，只要事情保持相对简单，这只是一个好的解决方案。 如果您需要存储更复杂的数据，请考虑找出更灵活的解决方案。
I'd probably just add a simple two-column table that's basically a key-value store. Then add a new column with values like
(featured_article_id, 45)or whatever the first featured ID is.Edit: as pointed out in the comments by rmeador, it should be noted that this is only a good solution as long as things stay relatively simple. If you need to store more complex data, consider figuring out a more flexible solution.
如果一次只能推荐一篇文章，那么添加布尔列就是一种浪费。 您应该上一级并为FeaturedArticleID 添加一列。 您有 Site_Settings 表吗？
If only one article can be featured at a time it is a waste to add a bool column. You should go up a level and add a column for the FeaturedArticleID. Do you have a Site_Settings table?
您可以使用可扩展模型，例如拥有属性表，然后使用链接表来形成文章和属性之间的多对多关系。 这样，这些类型的功能不需要修改架构。
You could use an extensible model like having a table of attributes, and then a linking table to form a many-to-many relationship between articles and attributes. This way, these sorts of features do not require the schema to be modified.
拥有某种带有parameter_name 和parameter_value 列的global_settings 表。 在此输入特色文章 ID。
Have some kind of global_settings table with a parameter_name and parameter_value columns. Put featured article id here.
对于像这样快速而肮脏的东西，我喜欢包含某种设置表：
如果您需要每个用户或每个客户的设置，而不是全局设置，您可以添加一列来将其标识给该特定用户/顾客。 然后，您只需为“FeaturedArticle”添加一行并从字符串中解析 ID。 它不是超级优化的，但纯文本非常灵活，这听起来正是您所需要的。
For quick-and-dirty stuff like this, I like to include some sort of Settings table:
If you need per-user or per-customer settings, instead of global ones, you could add a column to identify it to that specific user/customer. Then, you could just add a row for "FeaturedArticle" and parse the ID from a string. It's not super optimized, but plaintext is very flexible, which sounds like exactly what you need.