首先,我看到了一个ObjectID列,没有明确地将其声明为特定表的外键.然后你可以推送你想要的任何uniqueidentifier.这意味着您可能会从不属于我想要的4个表的表中插入ID.
其次,因为数据可能来自四个不同的表,我也看到人们制作了4个不同的外键.并且在这样做时,系统依赖于具有非NULL值的ONE AND ONLY ONE列.
这样做有什么好办法？例如,我的表中的记录可能会引用医院(ID),诊所(ID),学校(ID)或大学(ID)……但仅限于那些表.
谢谢！
解决方法
>您定义类型(建筑物),为其创建表格,为其指定主键
>您定义了两个或更多子类型(此处为Hospital,Clinic,School,University),为每个子类型创建表,生成主键…但主键也是引用Building表的外键
>现在可以使用外键在Building表上构建具有一个“ObjectType”列的表.您必须加入几张桌来确定它是什么类型的建筑物,但无论如何您都必须这样做.那,或存储冗余数据.
您已经注意到此型号的问题,对吧？什么阻止建筑物在两个或多个子类型表中输入？很高兴你问：
>向Building添加一个列,也许是“BuildingType”,比如char(1),允许值为{H,C,S,U},表示(duh)类型的建筑物.
>在BuildingID BuildingType上构建唯一约束
>在子表中有BulidingType列.对它进行检查约束,以便它只能设置为值(Hospitals表的H等).理论上,这可以是计算列;在实践中,由于以下步骤,这将无法工作：
>构建外键以使用两列关联表
Voila：给定一个类型为H的BUILDING行,SCHOOL表中的一个条目(类型S)不能设置为引用该Building
你会记得我确实说它很难实现.
事实上,最大的问题是：这值得做吗？如果有意义的是将四个(或更多,如时间)建筑类型实现为类型/子类型(进一步的规范化优势：一个地址用于地址和每个建筑物共有的其他属性,特定于建筑物的属性存储在子表中),构建和维护可能值得付出额外的努力.如果没有,那么你就回到原点：一个在现代普通RDBMS中难以实现的逻辑模型.
