这被认为是一个正常的形态失败?

当在“用户表”存储用户的宗教,因此,如果你看不起列,你会看到“基督徒”很多次,“穆斯林”很多次,等视为正常格式的失败? 哪种形式?

我看到它的方式:

  • 1NF:没有重复列。
  • 2NF:没有级联主键,所以这并不适用。
  • 3NF:有一个非关键属性没有依赖性。

存储用户的宗教这种方式似乎并没有任何失败的正常形态,但它似乎是非常低效的。 注释?

--------------解决方案-------------

您的设计支持所有的正常形态。 没关系,你的属性有一个字符串值。 该数据类型的大小是无关正常化。

规范化的目标不是物理存储效率 - 目的是为了防止异常。 并支持逻辑效率,即存储既定事实只有一次。 在这种情况下,事实上,在一个给定的行的用户是基督教。

原则的缺点,以这种方式存储的列是在存储空间中的行数可扩展至。

而不是一个字符列,您可以使用一个ENUM()如果你有一组固定的选择,很少,如果有的话,变化,仍然避免造成到这其中有一个外键宗教选择一个额外的表。 然而,如果选择将是流体,规范化规则更希望选择被置于它们自己的表,在用户表的外键。

还有,除了存储空间等优势,以保持他们在另一个表。 修改他们的是一个单元。 要改变ChristianChristianity ,你可以在宗教表中的单个变化,而 ​​不是做潜在地昂贵的(如果你有很多的行和宗教不被索引)

UPDATE users SET religion='Christianity' WHERE religion='Christian'

...你可以做的更简单,更便宜

UPDATE religions SET name='Christianity' WHERE id=123

当然,你也键控针对宗教表数据完整性。 变得不可能插入像拼错无效值Christain

我假设有有效的宗教的列表; 如果你刚刚进入自己的字符串用户,那么你必须将其存储在用户表,这是所有没有实际意义。

假设宗教都存储在自己的表。 如果您遵循公认的惯例,这个表将有一个主键是一个整数,而在其他表(如用户表)表条目的所有引用将外键。 存储宗教不违反任何正常形式的字符串方法(因为宗教的名义是宗教表中的候选键),但它确实违反不使用字符串作为键的做法。

(这是理论和关系代数的实践之间的有趣的差异从理论上讲,一个字符串,无异于一个整数不同;它们都是原子数学值在实践中,字符串有大量的开销,导致程序员不使用他们作为密钥。)

当然,也有可能的存储值的列表,每个都有自己的优点和缺点的其他方式(如ENUM一些RDBMS中)。

你的普通形式是有点歪。 第二范式是该行的其余部分依赖于“全键”。 第三范式的是,该行的其余部分依赖于“只不过是关键。” (帮帮我,科德)。

不,你所描述的情况不违反任何的前三个范式。 (这可能违反了第六,这取决于其他因素)。

有这种方法(相对于使用外键),你需要确保你都OK的几个缺点。 1 - 废弃物存储。 速度慢一些宗教3查询 - - 2有人可能把数据存在不匹配,如手工插入“绝”什么,你可能没有考虑正确的4 - 有没有办法有可能的宗教列表(例如,如果有您的表中,如没有一定的宗教之一,祆教),但你仍然希望它是一个有效的可能性,5 - 不正确的大写可能会导致问题6 - 字符串可能会导致问题周围的空白

这种技术主要是亲中的数据更快拔出(不加入桌面上),它也是快捷的为人类阅读。

分类:SQL 时间:2015-03-16 人气:256
本文关键词: 数据库,SQL,规范化
分享到:

相关文章

Copyright (C) 55228885.com, All Rights Reserved.

55228885 版权所有 京ICP备15002868号

processed in 0.246 (s). 9 q(s)