2011-09-15 118 views
-1

可能重复:
Should each and every table have a primary key?主键和数据库规范化

我一直对有关数据库规范化学校的项目。 我需要帮助的正常化有我在遇到困难没有主键 表一表,订阅一个表,它的结构是这样的:

itemSubscribed emailAddress 
-------------- ------------ 
1    [email protected] 
1    [email protected] 
1    [email protected] 
2    [email protected] 
2    [email protected] 
3    [email protected] 

注意itemSubscribedemailAddress值可能会重复,所以都不能成为主键。

这种结构将正常工作与我的代码,我可以发送电子邮件给所有项目X的用户时,有项X的更新,但我的老师需要一个规范化的数据库和1NF必须有一个主键。

如果我为了创建主键而创建了一个自动生成的主键,我不能继续使用3NF,因为它要求所有列都依赖于主键,所以w/c不是这种情况。

我应该创建一个自动生成的主键吗?我错过了关于3NF的一些事情吗?

+0

嗯,你忘了定义一个问题! – home

+1

尽可能难以复制占位符文本,最后忘记了这段时间。 – BoltClock

+0

我不能说这是一个答案,因为它已经关闭了,当然这有点晚了,但是......看起来你所描述的是一张桥表。桥表通常不是什么,而是一个复合主键。如果您将'itemSubscribed'和'emailAddress'列一起作为主键,则不会有任何重复项,并且它位于3NF中。自动生成的主键是您想要使用桥接表完成的最后一件事,因为它只会导致混淆和额外的工作,而实际上却鼓励重复。 – jmoreno

回答

0

您是否允许多次订阅一个项目的电子邮件地址相同?如果不是,你的自然关键是显而易见的:itemSubscribed和emailAddress。即使你在这种情况下选择了人造主键,你也可能需要在两列中有一个唯一的索引。

0

回答你的问题,是的,真的很难不拥有主键。数据库必须能够识别特定记录。假设你想更新下面以粗体显示的记录,但不是一个斜体。如果没有主键,你会如何做到这一点。

itemSubscribed EMAILADDRESS


1 [email protected]

1 [email protected]

1 [email protected]

在数据库类,如果你有没有主键的表,我会失败,这对数据库是至关重要的e设计。

现在我怀疑你不想居然有如图所示,除非你有这样的人不同的充其他列中的数据。为什么你真的想要两个订阅了相同条目的记录和相同的电子邮件地址?最好有一个PK或唯一索引来防止这类不良数据。我怀疑你真的有两个领域的天然关键,目前只有不好的数据。

1

一个表具有重复的行不表示关系。关系是一组元组。一套从来不会有相同的元素不止一次。一个包就像一个包,但可以有多个看起来完全相同的元素实例。

在你给我们的表中,我认为itemSubscribed是一个计数,itemSubscribed等于一个具有相同emailAddress的两行描述不同的事件。

但是,这是你的想法,而不是在数据中可见。

你会在这张桌子上遇到麻烦。特别是,无法区分错误的重复条目和两个看起来相似的有效条目。