可动态扩展的数据库模型设计
2013-09-10 14:23
246 查看
在通常的数据库设计中,我们定义了每个实体有多少个属性,每个属性的数据类型是什么,有多长,是否允许为空,有什么约束条件等,这些定义是完全静态的,系统创建时就全部定义好,不能动态修改。但是对于实体的属性变化很快,或者实体和属性由用户在系统中自行定义的情况下,那么就需要一个可以动态扩展的数据库模型,以保存各种动态产生的数据。
比如我们要做一个电子商务网站,需要建立一个商品表以保存各种要卖出的商品的属性。但是商品的属性各种各样,不同类别的商品在属性上千差万别,不可能建立一个静态的商品表来存储所有的属性。这个时候就需要建立动态的数据库模型。
常见的动态扩展的数据库设计方法有以下几种:
这样在每读取一个商品时,可以读取该商品的属性集合,然后将属性集合重新绑定到对象,将该对象暂时在页面上。
这种做法的优点是灵活,可以为商品创建无数个不同的属性,可以应对电商这种快速变化,快速上线的需求。缺点是后期做统计的时候会很慢,因为需要行转列,如果要涉及到各种Join查询之类的也会很麻烦。
在SharePoint 2007或者更早的版本中,对列表的数据存储就是采用这种方式,以下是SharePoint2007中的AllUserData表的结构。基本上为每种数据类型定义了十来个到几十个的列,用户在创建不同的列表时,都可以使用这个表存储列表数据。
这种数据库设计方法的优点是不会存在行转列的问题,所以在join或者出报表时性能较好,缺点就是使得一个表的列特别多,而且大部分列在大多数情况下是不使用的,而且扩展比较困难,比如我们要定义17个bit类型的列,但是系统默认只有16个,这种情况下,就需要在数据库中使用2行数据来表示1行列表数据。
对于前面提到的商品表和商品属性表,其实也可以只建立商品表,在该表中添加一XML类型的列,用于存储商品的各种属性。这是比较推荐的一种处理方法。
这种方法的优点是性能好,每个实体与其数据库表相对应,不存在大量的冗余列,也不会存在行转列的问题。缺点是开发难度大,对用户的要求高;而且在创建好实体并且存储了大量数据后,如果想要修改实体属性,那么将很困难。
比如我们要做一个电子商务网站,需要建立一个商品表以保存各种要卖出的商品的属性。但是商品的属性各种各样,不同类别的商品在属性上千差万别,不可能建立一个静态的商品表来存储所有的属性。这个时候就需要建立动态的数据库模型。
常见的动态扩展的数据库设计方法有以下几种:
一、以字符串存储各种数据类型,通过行转列实现实体属性读取。
以前提到的电子商务网站的商品实体为例,我们可以建立两个表“商品”和“商品属性”,商品表为普通的商品属性,可以将商品名称、价格等大部分商品的公共属性放到该表中。商品表与商品属性表形成一对多关系,商品属性表只需要定义商品“属性名”和“属性值”这两个属性用于保存一个商品的各个属性。这样在每读取一个商品时,可以读取该商品的属性集合,然后将属性集合重新绑定到对象,将该对象暂时在页面上。
这种做法的优点是灵活,可以为商品创建无数个不同的属性,可以应对电商这种快速变化,快速上线的需求。缺点是后期做统计的时候会很慢,因为需要行转列,如果要涉及到各种Join查询之类的也会很麻烦。
二、预定义大量的冗余列,根据用户对实体属性的类型设置匹配对应的列。
如果我们不希望行转列的话,那么可以预先定义好数据列,由于不确定是哪种数据类型,所以我们可以将表的列定义的特别多,每个不同的数据类型都定义几个或者十来个列,这些列都是允许为空的,如果没有使用已经预定义好的列,并不会占据多少数据空间。在SharePoint 2007或者更早的版本中,对列表的数据存储就是采用这种方式,以下是SharePoint2007中的AllUserData表的结构。基本上为每种数据类型定义了十来个到几十个的列,用户在创建不同的列表时,都可以使用这个表存储列表数据。
这种数据库设计方法的优点是不会存在行转列的问题,所以在join或者出报表时性能较好,缺点就是使得一个表的列特别多,而且大部分列在大多数情况下是不使用的,而且扩展比较困难,比如我们要定义17个bit类型的列,但是系统默认只有16个,这种情况下,就需要在数据库中使用2行数据来表示1行列表数据。
三、使用XML数据类型存储动态列数据。
XML数据类型是SQL的一个标准,目前主流的数据库都支持XML数据类型,数据库为XML提供专门的语法以快速检索和操作XML数据。在新版的SharePoint中,就使用XML来存储用户自定义列表的内容。对于前面提到的商品表和商品属性表,其实也可以只建立商品表,在该表中添加一XML类型的列,用于存储商品的各种属性。这是比较推荐的一种处理方法。
四、为用户定义的实体动态创建表。
还有一直动态方法是在程序中动态创建表,用户每在程序中定义一个实体的时候,就好根据用户定义创建一个对应的表。比如微软的Dynamic CRM就是这样实现的。用户可以在系统中创建大量的实体,并且还可以定义实体之间的关系,系统就会按照用户的定义创建对应的表,以及外键。这种方法的优点是性能好,每个实体与其数据库表相对应,不存在大量的冗余列,也不会存在行转列的问题。缺点是开发难度大,对用户的要求高;而且在创建好实体并且存储了大量数据后,如果想要修改实体属性,那么将很困难。
相关文章推荐
- 可动态扩展的数据库模型设计
- 数据库字段动态扩展设计
- 微服务-动态表单数据库设计模型(关系数据库和非关系数据模型MongoDB)
- [导入]数据库物理模型设计的其他模式之单表模式
- 按Sybase的PowerDesigner工具设计的数据库模型 ---> 解析生成能兼容多种数据库的相应的C#底层代码
- 数据库表扩展字段设计思路
- MySQL数据分析-(5)数据库设计之ER模型
- 设计组织树 通过java拼接xml组织树 实现界面组织树 通过数据库配置动态决定菜单树显示与否、排列优先
- 商城数据库设计原则(二)-商品模型的设计
- 数据库设计--主扩展模式(转)
- 第七章 数据库设计 E-R模型
- 建模软件应用设计BIM模型_BIM数据库【住建BIM数据库】
- 《Entity Framework 6 Recipes》中文翻译系列 (38) ------ 第七章 使用对象服务之动态创建连接字符串和从数据库读取模型
- 存储动态数据时,数据库的设计方法
- MySQL之数据库模型设计-1 第一范式、第二范式、第三范式理解
- 动态表单数据库设计
- 数据库表扩展字段设计思路
- 按Sybase的PowerDesigner工具设计的数据库模型 ---> 解析生成能兼容多种数据库的相应的C#底层代码
- 数据库物理模型设计的其他模式
- 数据库设计---PowerDesigner(物理模型和概念模型)