小编And*_*ini的帖子

我有一个相当简单的问题,关于自然/代理关键用法在明确定义的背景中经常表现出来,并且我将说明.

假设您正在使用SQL Server 2005作为DBMS设计产品的数据库模式.为简单起见,假设只涉及两个实体,它们已映射到2个表,Master和Slave.假使,假设:

1. 对于单个Master的行,我们可以有0..n Slave条目;
2. Master中的列集(A,B,C,D)是主键的唯一候选者;
3. Master中的B列随时间变化 ;
4. A,B,C,D是varchar,decimal和bigint列的混合.

问题是:您将如何为这些表设计键/约束/引用？你愿意(争论你的选择):

1. 在Master上的(A,B,C,D)和Slave上的相关复合外键上实现复合自然键,或
2. 在Master上引入代理键 K,比如在Slave上带有相关(单列)外键的IDENTITY(1,1)列,在Master(A,B,C,D)上添加UNIQUE约束,或者
3. 使用不同的方法.

至于我,我会选择2),主要是因为假设3)和表现方面,但我想听听别人的意见(因为关于这个话题有相当公开的辩论).

谢谢

在我们的数据库模型中,我们有一个受益人实体.受益人可以是自然人或公司受益人; 一个物理受益人有许多属性,如姓名,性别等; 此外,受益人(公司或自然人)可以是外国的,也可以不是; 这种进一步的区别转化为"共同"属性集的不同域值(例如,在我居住的意大利,税ids可能具有与英国税ids不同的数据格式).

我们现在正在重新设计受益人表,因为最初从事数据库分析和建模工作的开发人员做了一个(IMO)短视选择.他将主键约束放在属性BeneficiaryName上,用于存储公司名称(例如"Microsoft Corporation")(如果是公司受益人)或姓氏(例如Smith)用于实际受益人.这样我们就有了(不可接受的)约束,我们的数据库中不能有超过1名姓氏为"Smith"(或名为"Smith"的公司)的受益人.

我对这种"重新分解"的方法将引入受益人实体的概括; 我会

1. 清洁受益人表,仅保留常见数据;
2. 将一个代理主键添加到受益人表,我们称之为BeneficiaryID;
3. 拆分受益人表,创建两个子实体(CorporateBeneficiary&PhysicalBeneficiary,受主受益人表中的标志区分),与受益人表的1..1关联(外键将参考BeneficiaryID)
4. 查找(有意义的)CorporateBeneficiary和PhysicalBeneficiary的主键;

这应该解决上述BeneficiaryName的唯一性问题.到目前为止似乎还可以吗？

我遇到的真正问题是:我该怎样/应该如何处理这个模型中"外来"属性所增加的复杂性？我应该留下外国,即受益人的旗帜属性吗？如果是这样,我如何处理对于概念上类似的信息(即邮政编码,税号)以及重复属性(zipcode_foreign,zipcode,taxid_foreign,taxid等)的不同属性的需求？我是否真的应该努力将不同的域值容纳到一个字段中？

任何建议都会受到欢迎......