逻辑数据库设计 - 多态关联

多态关联

  先说明什么是多态关联。

  假设我们有一张地址表,其中的地址可能是对于User中的,也可能是对于Orders中的。

  

  以上,只是举个例子,实际的例子还有很多,比如我们要设计一个内容管理系统(CMS),我们的CMS有一个文章表,一个软件表。还要求支持评论,那么我们的评论表的Id是引用文章表还是引用软件表呢?

  对于以上例子的缺点,貌似书本上有故意为此多态关联的模式走软的嫌疑。缺点不说了,主要是查询麻烦,其次不能够支持外键约束。

解决方案

  交叉表

  对于这种需要外键引用为多个表的情况,可以建立一张交叉表。让Address不再依赖Orders或Users。

  

  优点:

  引用完整性支持。

  缺点:

  如果我们希望一个给定的地址,只能够在一张交叉表中出现一次,上面的复合主键已经做到了。如果希望一个地址可以在一张交叉表中出现多次,可以取消复合主键。但是不能够保证一个地址不在多张交叉表中出现,这需要我们再程序代码中实现。

  实际上,多态关联与上篇文章提到的,实体-属性-值有关系。

  如果前面采用的是类表的设计,根本不会出现这个问题,上面的地址,也可以依赖倒置。比如在Order表中添加一个AddressId、User表中添加一个AddressId解决。

  假设,采用类表继承的方法。直接将Address用外键指向基表就OK了根本就没这个问题。书中的这一篇写得有点莫名其妙。既然我已经写完了,算了,不管了。

时间: 2024-08-02 21:10:21

逻辑数据库设计 - 多态关联的相关文章

逻辑数据库设计 - 单纯的树(递归关系数据)(转)

逻辑数据库设计 - 单纯的树(递归关系数据) 相信有过开发经验的朋友都曾碰到过这样一个需求.假设你正在为一个新闻网站开发一个评论功能,读者可以评论原文甚至相互回复. 这个需求并不简单,相互回复会导致无限多的分支,无限多的祖先-后代关系.这是一种典型的递归关系数据. 对于这个问题,以下给出几个解决方案,各位客观可斟酌后选择. 一.邻接表:依赖父节点 邻接表的方案如下(仅仅说明问题): CREATE TABLE Comments( CommentId int PK, ParentId int, --

逻辑数据库设计 - 需要ID(谈主键Id)

本文的目标就是要确认那些使用了主键,却混淆了主键的本质而造成的一种反模式. 一.确立主键规范 每个了解数据库设计的人都知道,主键对于一张表来说是一个很重要,甚至必需的部分.这确实是事实,主键是好的数据库设计的一部分.主键是数据库确保数据行在整张表唯一性的保障.它是定位到一条记录并且确保不会重复存储的逻辑机制.主键也同时可以被外键引用来建立表与表之间的关系. 难点是选择那一列作为主键.大多数表中的每个属性值都有可能被很多行使用.例如姓名,电子邮件地址等等都不能保证不会重复. 在这样的表中,需要引入

逻辑数据库设计 - 无视约束(谈外键)

有一些开发人员不推荐使用完整性约束,你可能听过以下这么几点不使用外键的原因. 1.数据更新有可能和约束冲突. 2.当前的数据库设计如此灵活,以致于不支持引用完整性约束. 3.数据库为外键建立的索引会影响性能. 4.当前使用的数据库不支持外键. 5.定义外键的语法并不简单,还需要查阅. 一.反模式:无视约束 即使第一感觉告诉你,省略外键约束能使得数据库设计更加简单.灵活,或者执行更加高效,你还是不得不在其他方面付出相应的代价 -- 必须增加额外的代码来手动维护引用完整性. 1.完整性问题 很多人对

逻辑数据库设计 - 可变属性(继承)

可变属性的需求:我们需要在数据库里面存储很多电器,比如电视,冰箱等等.通常,在程序中,我们的类图为: EVA设计 对于这种继承下来的可变属性时,有一种办法是创建另外一张表,将属性当成行来存储. 其中存储的数据类似下面这样: 这样的设计称为:实体-属-值,简称:EVA,或者又叫开放架构.无模式. 这种设计有如下3种好处: 1.这两张表的列都很少. 2.新增的属性不会对现有的表结构造成影响,不需要新增列. 3.避免由于空值而造成的表内容混乱. 但是这样也有如下缺点: 1.查询属性 本来,我们想要按出

逻辑数据库设计 - 单纯的树(递归关系数据)

相信有过开发经验的朋友都曾碰到过这样一个需求.假设你正在为一个新闻网站开发一个评论功能,读者可以评论原文甚至相互回复. 这个需求并不简单,相互回复会导致无限多的分支,无限多的祖先-后代关系.这是一种典型的递归关系数据. 对于这个问题,以下给出几个解决方案,各位客观可斟酌后选择. 一.邻接表:依赖父节点 邻接表的方案如下(仅仅说明问题): CREATE TABLE Comments( CommentId int PK, ParentId int, --记录父节点 ArticleId int, Co

逻辑数据库设计 - 元数据分裂(分区表)

我之前曾参与维护过一个舆情监控系统,该系统每天源源不断地监控着互联网上的新闻,不断从网上下载新闻保存进入数据库. 提出问题 为了表述简单,我特意模拟了一张类似的表: CREATE TABLE NEWS( Id int PK, Title nvarchar(500) --新闻标题 Content text --新闻内容 CreateTime DateTime) 随着时间的推移,数据库里的新闻变得越来越多,系统开始跑得越来越慢.随后,技术经理考虑到,舆情监控需要的仅仅是近期的数据,过时的数据,不太重

逻辑数据库设计 - 乱穿马路(多对多关系)

一.乱穿马路模式介绍 程序员通常使用逗号分隔的列表来避免在多对多关系中创建交叉表,这种设计方式定义为一种反模式,称为乱穿马路. 例如:在一个产品管理系统中,一个人可以有多个产品,一个产品必须对应一个人,因此有如下数据库: 但是,随着时间的推移,出现了一个产品可能会有多个联系人.于是为了最小限度地修改数据库,可能不少人会将Account_Id的类型修改成varchar,这样就可以列出该列中的多个账号Id,每个Id之间用逗号分隔.这样的设计貌似可行,因为并没有创建额外的表或者列.仅仅改变了一个字段的

逻辑数据库设计 - 多列属性(多列转行)

假设有一个要开发一个试题系统,全是不定项选择题.一道题可能有2,3,4...个答案,数据应如何设计呢?本处旨在说明问题所在,例如同类问题还有存储电话,一个人可能有多个号码等等. 一.存储多值属性 反模式:创建多个列. 我们知道每列最好只存储一个值,因此先看如下设计: CREATE TABLE Question( QuestionId int PK, QuestionBody nvarchar(500), Answer1 nvarchar(500), Answer2 nvarchar(500),

DBA词典:数据库设计常用词汇中英文对照表

1. Access method(访问方法):此步骤包括从文件中存储和检索记录. 2. Alias(别名):某属性的另一个名字.在SQL中,可以用别名替换表名. 3. Alternate keys(备用键,ER/关系模型):在实体/表中没有被选为主健的候选键. 4. Anomalies(异常)参见更新异常(update anomalies) 5. Application design(应用程序设计):数据库应用程序生命周期的一个阶段,包括设计用户界面以及使用和处理数据库的应用程序. 6. Att