She*_*hef 4 database database-design relational-database database-schema database-normalization
考虑一下这个表:
+-------+-------+-------+-------+
| name |hobby1 |hobby2 |hobby3 |
+-------+-------+-------+-------+
| kris | ball | swim | dance |
| james | eat | sing | sleep |
| amy | swim | eat | watch |
+-------+-------+-------+-------+
爱好的类型没有优先权,因此所有的爱好都属于同一个领域.也就是说,表格中的爱好可以在任何hobby#列上移动.无论哪一列,特定的爱好都可以在任何列中.
该表违反了哪个数据库规范化规则？
问:"业余爱好列表是否按任意顺序"？
答:是的.
问:表格有主键吗？
答:是的,假设密钥是一个AUTO_INCREMENT名为的列类型user_id.
问题是列hobby#是否重复组.
旁注:这不是作业.这是一种辩论,它始于 SQL问题的评论 - 基于几个列将记录从一个表匹配到另一个表.我相信这个问题是违反1NF的明显例子.
然而,另一个人认为我" 已经堕落了1NF的谬误之一. "这个论点是基于" 关于第一范式的事实和谬误 "的"重复群体的模糊性" 一节.
我不是写这个来羞辱他,我或任何人.我写这篇文章,因为我可能错了,而且我有一些东西显然是错过的,也许这个家伙并没有对我说好.
Joe*_*own 10
你说爱好属于同一个域,他们可以在列中移动.如果这意味着,对于任何特定name的爱好列表是任意顺序和kriss可以很容易地跳舞,球,游泳,游泳,跳舞,然后我会说你有一个重复组和表违反1NF.
另一方面,如果某个人的第一和第二爱好之间存在一些基本的语义差异,那么可能存在一个论据,即爱好不是重复组,而且表可能在3NF(假设爱好列是FK到业余爱好表).我建议这个论点,如果它存在,是弱的.
另一个要考虑的因素是为什么正好有3个爱好以及是否有更多或更少的爱好是潜在的问题.这个因素对于归一化和设计灵活性来说并不重要.这是我将业余爱好分成行的一个原因,即使它们在语义上彼此不同.
你的三个爱好表设计可能违反我通常所说的原始1NF 的精神(可能是由于dportas和其他人给出的原因).
然而事实证明,找到一套准确表达原始"精神"的正式和精确的"可衡量"标准是非常困难的.这就是你的另一个人试图解释的"重复群体的模糊性".
在这里强调"正式","精确"和"可衡量".存在满足"形式","精确"和"可测量"(即客观可观察)的所有其他正规形式的定义.对于1NF来说,这很难(/不可能).如果你想知道原因,试试这个:
你说问题是"这三个业余列是否构成一个重复的群体".用"是"回答这个问题,然后为你的答案提供严格的正式基础.
您不能只说"列名相同,但编号后缀除外".违反这一规则是客观上可观察/可衡量的,需要列举所有可能的后缀方法.
你不能只说"游泳,网球"同样可以成为"网球,游泳",因为要知道这肯定需要检查桌子的外部谓词.如果那只是"人<姓名>有爱好<爱好1>并且还有<爱好2>",那么两者确实同样有效(除了:并且由于世界封闭的假设,事实上它需要所有可能的爱好排列到出现在表!!!).但是,如果外部谓词是"人<名>上花费时间最多的<hobby1>及至少在<hobby2>",然后在"游泳,网球"可能不同样是"网球,游泳".但是,如何对表目标的外部谓词进行这样的解释(对于所有可能的预测)？
等等
这显然"看起来"像设计错误.
简单地存储和检索此数据时,这不是设计错误.您只需要3个爱好,并且您不打算以任何其他方式使用此数据而不是检索.
让我们考虑一下这种关系:
然后这个表似乎设计得很好,虽然1NF惯例受到尊重,但命名可能会"糟透了".
在不分青红皂白地存放爱好的情况下,如果不是所有我现在都能想到的情况,这显然是错误的.您的表有重复的行,违反了1NF原则.
当您需要为分页或任何其他实际原因对结果进行排序时,不要考虑SQL请求从此表访问数据的效率降低.
让我们考虑当您的数据库被其他开发人员或团队使用时,处理数据所需的工作:
你基本上会产生沮丧,愤怒和仇恨,而且力量会受到干扰.