数据库设计 – 我的数据是否已标准化？

>多对多关系是一个逻辑概念,并在逻辑模型中绘制.它们在物理模型中实现为关联表.我提供了那个.规范化数据库有更多的表(没什么好害怕的),但每个表的列数更少,没有重复的列(没有更新异常).
>哦,天哪. Topic和SubTopic列很大！我们无法将那些胖外键迁移到Question中. [与商业用户讨论.]好的,他们说只有一百个主题和几千个子主题.不需要NUMERIC(10,0).他们想要在下拉菜单中使用完整的Topic和Subtopic,并且他们同意它必须是唯一的,但是额外的短CHAR(6)代码会很好.

看,它确实来回走动.纸很便宜;与任何人和每个人讨论;改进,纠正,改变,调整,改进,而无需创建单个表或编写一行代码;在你将有一个值得编写代码的模型.别的不是.学习的唯一方法是提出坚实的东西,并将其击退或改变;把所有的错误写在纸上,而不是在数据库中.

请注意,Surrogate键始终是一个附加键,一个附加索引.它们永远不能代替Key(这就是你所拥有的,以及Eddie试图让你思考的东西：你没有防止重复,你只是有一个毫无意义的关键保证行是唯一的,就像电子表格一样;和虚假的安全感).因此,我们需要尽量减少它们,而不是在每张桌子上刻上它们.

我希望我已经在上面展示过,诸如“从不使用代理人”和“总是使用代理人”之类的简单规则太难以讨论.不,仔细建模意味着：理解并认为它们是额外的,而不是替代真正的密钥.仅在必要时使用,并在必要时使用它们.在这里,我设法逃脱了一个IDENTITY.对用户有意义的三个短代码是代理人,但它们有意义; IDENTITY列没有(它们最终具有意义,它们无法支持,这是问题的一部分).

我将把DataTypes留给你.但请记住,varchars和Nullable列强制列可变.如果在索引中使用它真的很慢(每个条目都必须在每次访问时都有一些“解包”,即使是中间级别),所以必须避免,除非你想为老板提供一个慢速数据库.

同样,如果您不希望页面上的行开销在每个UPDATE上移动,则固定长度的列都在周围.这意味着我们不能懒惰和varchar一切.

好的,现在我们有一个容纳火箭燃料的室.

对评论的回应1

从你的上一个数据模型中,如果我从问题表中省略了topicCode会更好吗？在子主题和问题表中包含topicCode是不是觉得多余？

好问题.

(最后一个,第五个是数据模型;第四个是实体关系图;前三个是天空中的馅饼,到达那里.)

>在子项中作为外键迁移的主键不是多余的,它是必需的.
> Subtopic PK是(TopicCode,SubtopicCode),复合键(商业数据库支持,作为关系模型的要求).在Subtopic的水平线上方.

>一些开发人员害怕复合键,因为它们在WHERE子句中需要多个引用(纯粹的懒惰; SQL对于连接很麻烦;处理它).
.

>那是因为关系Topic :: Subtopic是一个识别关系,这意味着Parent的PK用于构造Child的PK,形成一个Compound Key.请注意,无论如何,父PK必须作为FK携带在Child中,因此它不是多余的;这是必需的.众所周知,这会大大增加数据库的“功率”或“关系性”,并且大大增加了易用性(高级用户通常比开发人员更擅长使用RDb).

>这就是它被确定为标准的原因：IDEF1X是一种强制执行更严格的关系模型应用的标准;它促进了对所有密钥的深思熟虑,这当然对所谓的关系数据库的“关系性”至关重要.
.

>问题是,FK到Subtopic因此是(TopicCode,SubtopicCode).
>如果你在Topic和SubTopic中使用了ID,那么Question会有(SubtopicId)作为FK到Subtopic,你会失去导航能力和意义.

（编辑：瑞安网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!