2014-10-11 17:21:31
目标：支持可变属性
反模式：使用泛型属性表。这种设计成为实体-属性-值（EAV），也可叫做开放架构、名-值对。
优点：通过增加一张额外的表，可以有以下好处
（1）表中的列很少；
（2）新增属性时，不需要新增列。不会影响现有表的结构；
（3）存储的字段内容不会为空值。
缺点：（1）查询语句变得更加复杂；
（2）使用EAV设计后，需要放弃传统的数据库设计所带来的方便之处，比如：无法保障数据完整性；
（3）无法使用SQL的数据类型，比如对日期、金钱等格式内容都只能保持为字符串类型；
（4）无法确保引用完整性；
（5）无法配置属性名。比如，有可能表中存在两条记录，
一条的attr_name是sex，一条attr_name是gender，都是表示性别；
（6）查询结果中有多个属性时，查询非常困难，且查询性能无法控制。
如何识别反模式：当出现以下情况时，可能是反模式
（1）数据库不需要修改元数据库（表中的列属性）就可以扩展。还可以在运行时定义新的属性。
（2）查询是连接数量非常多，且连接的数量可能会达到数据库的限制时，你的数据库的设计可能是有问题的。
（3）普通的报表查询变的及其复杂甚至不且实际。
合理使用反模式：
（1）关系数据库中使用EAV，就意味着放弃许多关系数据库范式的优点。
但是这不影响在某些程序中合理地使用这种设计来支持动态属性。
（2）如果有非关系数据管理的需求，那最好的方法就是使用nosql数据库。
在传统数据库中使用EAV设计的缺点也体现在这些非关系数据库上。当元数据不具有固定格式时，
再简单的查询都会变得非常困难。上层应用就需要花费更多的时间、精力来组织数据结构。
解决方案：模型化子类型
1、单表继承：所有属性都在一个单表上保存，增加属性时就扩充这个表。
当数据的子类型很少，以及子类型特殊属性很少，就可以使用单表继承。
缺点：（1）当程序需要加入新对象时，必须修改数据库来适应这些新对象。又由于这些新对象具有一些和老对象不用的属性，
因而必须在原有表里增加新的属性列，可能会遇到一个实际的问题，就是每张表的列的数量是有限制的。
（2）没有任何的元信息来记录哪个属性属于哪个子类型。
2、实体表继承：为每个子类型创建一张独立的表，每个表包含哪些属于基类的共有属性，同时也包含了子类型特殊化的属性。
优点：（1）实体继承类设计相比于但表继承设计的优势在于提供了一种方法，
让你能组织在一行内存储一些和当前子类型无关的属性。
如果你引用一个并不存在于这张表中的属性列，数据库会自动提示你错误。
（2）不用像在单表继承设计里那样使用额外的属性来标记子类型。
缺点：很难将通用属性和子类特有属性区分开来。因此，如果将一个新的属性增加到通用属性中，
必须为每个子类表都添加一遍。
当你很少需要一次性查询多有子类型时，实体继承表设计是最好的选择。
3、类表继承：把表当成面向对象里的类。
创建一张基类表，包含所有子类型的公共属性。对于每个子类型，创建一个独立的表，通过外键和基类表相连。
4、半结构化数据模型：如果有很多子类型或者必须经常增加新的属性支持，那么可以用一个BLOB列来存储数据，
用XML或者JSON格式——同事包含了属性的名字和值。这叫做序列化大对象块。
这个设计的优势是扩展性，缺点是，这样的结构中sql无法获取某个指定的属性。你必须或者整个blob字段并通过程序去解释这些属性。
当你需要绝对的灵活性时，可以使用这个方案。
如果使用了EAV，那么可以先将全部属性取出，然后再做其他处理。
结论：Sql已经提供了一个方法来明确的定义属性——在明确的列中。即：为元数据使用元数据。