数据库的坏味道 --《Refactoring Database: Evolutionary Database Design》读书笔记

 

2010年6月2日

 

多目的列(Multipurpose column)

如果一列有多个目的，就很可能存在额外的代码通过检查其它一列或多列的值来保证该数据以“正确”的方式使用。例如Person中有一个日期列，对于顾客存储生日，对于员工存储入职日期。更糟的是你能做的事受到了限制，例如，如何存储员工的生日信息？

多目的表(Multipurpose table)

类似的，一张表存储多种类型的实体时，很可能就是一个设计缺陷。例如用一个顾客表既存放个人客户，也存放公司客户信息。这种方法的问题在于个人和公司的数据是不一致的。个人有姓有名，但公司只有一个法律名称。一张通用的顾客表有些字段会对某类顾客为空，但对其它顾客非空。

冗余数据(Redundant data)

冗余数据对于操作中的数据库(Operational databases?)是一个严重问题。因为数据存储在多个位置就可能出现不一致。一个很常见的例子是在你的组织中顾客信息存储在很多不同地方。实际上很多公司没有一张他们顾客究竟是哪些人的准确列表。容易产生这样的问题：一张表中张三住在解放路，另一张表中他住民主路。实际上张三去年从解放路搬到了准海路，但他没有在你们公司的两个应用里更新地址信息。

太多列的表(Tables with too many columns)

一张表有太多列通常意味着它组织松散，想储存来自多个实体的数据。你的顾客表中可能包含了三种不同的地址(发货地址，付账地址，季节性的地址)(原文shipping, billing, seasonal?)或者几种不同的电话号码（家庭，工作地点，移动电话和其它）。或许你需要通过添加地址和电话号码表来正规化这种结构。

太多行的表(Tables with too many rows)

大表意味着性能问题。例如搜索包含百万列的表是耗时的。你或者需要利用垂直切分把一些列放到另外的表去，或者通过水平切分把一些行放到另外表去。两种策略都减少了表的大小，因而潜在的提升了性能。

聪明的列("Smart" columns)

聪明的列是数据不同位置表示不同概念。例如，客户id前4位表示客户的国内分支机构。那么客户id就是一个聪明列，因为你能解析它来获得更细粒度的信息(例如分支机构id).用文本列来储存xml数据是另一个例子。显然你能通过解析xml获得更小的数据域。聪明列通常需要在某种程度上重新组织为它们的成员数据以便数据库能更容易的将其作为独立元素进行处理。

惧怕改变(Fear of change)

如果你因为担心把某些事搞砸--例如50个访问数据库的程序 --而害怕改变你的数据库结构，那这就是最清晰的信息--该重构了。惧怕改变意味着你在技术上有一个定时炸弹。随着时间流逝问题只会更糟。