在通常的数据库设计中,我们定义了每个实体有多少个属性,每个属性的数据类型是什么,有多长,是否允许为空,有什么约束条件等,这些定义是完全静态的,系统创建时就全部定义好,不能动态修改。但是对于实体的属性变化很快,或者实体和属性由用户在系统中自行定义的情况下,那么就需要一个可以动态扩展的数据库模型,以保存各种动态产生的数据。
比如我们要做一个电子商务网站,需要建立一个商品表以保存各种要卖出的商品的属性。但是商品的属性各种各样,不同类别的商品在属性上千差万别,不可能建立一个静态的商品表来存储所有的属性。这个时候就需要建立动态的数据库模型。
常见的动态扩展的数据库设计方法有以下几种:
以前提到的电子商务网站的商品实体为例,我们可以建立两个表“商品”和“商品属性”,商品表为普通的商品属性,可以将商品名称、价格等大部分商品的公共属性放到该表中。商品表与商品属性表形成一对多关系,商品属性表只需要定义商品“属性名”和“属性值”这两个属性用于保存一个商品的各个属性。
这样在每读取一个商品时,可以读取该商品的属性集合,然后将属性集合重新绑定到对象,将该对象暂时在页面上。
这种做法的优点是灵活,可以为商品创建无数个不同的属性,可以应对电商这种快速变化,快速上线的需求。缺点是后期做统计的时候会很慢,因为需要行转列,如果要涉及到各种Join查询之类的也会很麻烦。
如果我们不希望行转列的话,那么可以预先定义好数据列,由于不确定是哪种数据类型,所以我们可以将表的列定义的特别多,每个不同的数据类型都定义几个或者十来个列,这些列都是允许为空的,如果没有使用已经预定义好的列,并不会占据多少数据空间。
在SharePoint 2007或者更早的版本中,对列表的数据存储就是采用这种方式,以下是SharePoint2007中的AllUserData表的结构。基本上为每种数据类型定义了十来个到几十个的列,用户在创建不同的列表时,都可以使用这个表存储列表数据。
这种数据库设计方法的优点是不会存在行转列的问题,所以在join或者出报表时性能较好,缺点就是使得一个表的列特别多,而且大部分列在大多数情况下是不使用的,而且扩展比较困难,比如我们要定义17个bit类型的列,但是系统默认只有16个,这种情况下,就需要在数据库中使用2行数据来表示1行列表数据。
XML数据类型是SQL的一个标准,目前主流的数据库都支持XML数据类型,数据库为XML提供专门的语法以快速检索和操作XML数据。在新版的SharePoint中,就使用XML来存储用户自定义列表的内容。
对于前面提到的商品表和商品属性表,其实也可以只建立商品表,在该表中添加一XML类型的列,用于存储商品的各种属性。这是比较推荐的一种处理方法。
还有一直动态方法是在程序中动态创建表,用户每在程序中定义一个实体的时候,就好根据用户定义创建一个对应的表。比如微软的Dynamic CRM就是这样实现的。用户可以在系统中创建大量的实体,并且还可以定义实体之间的关系,系统就会按照用户的定义创建对应的表,以及外键。
这种方法的优点是性能好,每个实体与其数据库表相对应,不存在大量的冗余列,也不会存在行转列的问题。缺点是开发难度大,对用户的要求高;而且在创建好实体并且存储了大量数据后,如果想要修改实体属性,那么将很困难。