数据库中是否存在区分内容类型的细线？
嗯，我想提供多种不同的内容类型。有些非常相似，我觉得它们属于同一类别。不过，有些列适用于某些内容类型，但不适用于其他内容类型。我应该将它们全部存储在 nodes 表中，还是应该为每个内容类型 创建一个新表？我应该根据不兼容的列来分解表格吗？
以下是一些示例内容类型：书籍、博客条目、广告、个人资料、焦点故事、档案故事、静态页面、联系表单、测验、民意调查。
我一直在考虑像这样拆分表：
post: book, spotlight story, archival story, blog entry
questionnaire: quiz, poll
static: static page, profile
ad
contact form
不幸的是，在阅读有关数据库规范化的内容后，我并不清楚哪种方法最好，但我在理解第三范式之外的任何内容时遇到了很大的困难。当我开始阅读第三范式时，我发现特别令人不安的是，工业界的人们常常为了速度而故意忽视遵守它。因此，如果有人可以用我的例子来让我清楚什么是真正合理的，我将非常感激。
Well, I have a number of different content types that I want to make available. Some are so similar, I feel they belong in the same category. There are columns that apply to come of the content types and not to others, though. Should I store them all in a nodes table, or should I create a new table for each content type? Should I break the tables up over incompatible columns?
Here are some examples content types: book, blog entry, ad, profile, spotlight story, archival story, static page, contact form, quiz, poll.
I've been thinking about splitting the tables up like this:
post: book, spotlight story, archival story, blog entry
questionnaire: quiz, poll
static: static page, profile
ad
contact form
It wasn't apparent to me which method was best after reading about database normalization, unfortunately, but I had a great deal of trouble understanding anything beyond the third normal form. What I found particularly troubling when I started reading about third normal form was that people in industry often neglect to adhere to it intentionally, for the sake of speed. So, if anyone could use my example to bring me some clarity about what's actually reasonable, I would really appreciate that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
TL;DR：这要看情况。
规范化意味着您将拥有一个用于公共属性的表，以及用于每种类型的独特属性的单独表。如果有大量的公共属性，并且将共享这些属性的每个类型称为相同的“超级类型”是有意义的，那么我更喜欢这样做。
如果速度很重要，您可能不想这样做，因为每次访问其中一种子类型时都会强制进行连接。这种程度的调整是否有意义取决于很多因素。
如果每个子类型都有“少量”唯一属性，则将类型和每个属性存储在单个表中（“单表继承”）可能会很容易，或者如果速度实际上 成为一个问题。
另一种选择是实际上两者兼而有之：保留关系模型，但使用触发器来保留平面数据的集合。我不确定这在您的情况下是否有意义，因为可能不会有“大量”连接 - 但对于非常复杂的数据库模型，它很方便，尤其是对于报告。
TL;DR: It depends.
Normalization implies you'd have a table for the common properties, and separate tables for each type's unique properties. If there's a large number of common properties, and it makes sense to refer to each of the types that share those properties as the same "super type", then I prefer this.
If speed matters, you may not want to do this, as it will force a join every time you access one of the sub-types. Whether or not that level of tuning is meaningful depends on a bunch of things.
If each sub-type has a "small" number of unique properties, it might be just as easy to store a type and each property in a single table ("single table inheritance"), or if speed actually becomes an issue.
Another option is to actually do both: keep a relational model, but use triggers to keep a collection of flat data. I'm not sure that makes sense in your case, since there probably wouldn't be a "large" number of joins--but for really complicated DB models, it's handy, especially for reporting.