数据库味道

Fowler在他的著作中引入了“代码味道”的概念，它是代码中的一类常见问题，表明需要进行重构。常见的代码味道包括switch语句，长方法，重复代码，特性羡慕等。有一些常见的数据库味道，表明可能需要进行重构。这些味道包括：

• 多用途的列。如果一个列被用于多种用途，就有可能存在额外的代码来确保源数据以“正确的方式”使用，这些代码常常会检查一个列或更多其他列的值。一个例子是：一个列用于存储某人的生日，如果此人是顾客的话。但如果此人是公司雇员，这个列就用于存储此人进公司的日期。更糟糕的是，你可能在目前能支持的功能上受到限制–例如，如何存放雇员的生日？
• 多用途的表。类似地，如果一个表被用于存放几种类型的实体，就可能存在设计缺陷。例如，一个通用的Customer表中存放人和公司的信息。这种方式的问题在于，人和公司的数据结构式不一样的，人有名有姓，而公司只有一个法定名称。一个通用的Customer表中可能包含一些列，对某些类型的客户来说这些列为空，而对另一些类型的客户来说这些列不为空。
• 重复的数据。重复的数据对操作型(operational)数据库来说是个严重的问题，因为数据存放在几个地方，不一致的机会就增加了。例如，常常会发现顾客信息被存放在组织机构中的许多不同地方。实际上，许多公司不能集中得到一份准确的清单，说明谁是他们的客户。问题在于，一个表中的John Smith住在Main大街123号，而一个表中的John Smith住在Elm大街456号，在这个例子中，实际上只有一个人，以前住在Main大街123号，去年搬到Elm大街456号。不幸的是，John没有向贵公司提交两份地址变更表格，你的每个一直到他的应用都需要进行地址变更。
• 列太多的表。当一个表包含太多的列时，说明这个表缺乏内聚– 它试图存放自己类试题的数据。也许你的Customer表包含了一些列，存放了3个不同的地址（发货地址，账单地址，季节性地址）或几个电话号码（家庭电话，工作电话，移动电话等等）。你可能需要将这种结构进行标准化处理，假如Address和PhoneNumber表
• 行太多的表。大的表往往有性能问题。例如，在一个几百万行的表中查找时很花时间的。你可能需要对该表进行垂直分割，将一些列移到另一个表中，或者进行水平分割，将一些行移到另一个表中。这两种策略都会减小表的规模，可能改善性能。
• “智能”列。智能列是这样一种列。其中数据的不同位置代表不同的概念。例如，如果客户ID的前4位代表客户的开户行(home branch)，那么客户ID就是一个智能列，因为你会解析它以取得更细粒度的信息。另一个例子是使用一个文本列来保存XML数据结构；很清楚，你需要解析XML数据结构获得粒度更小的数据字段。智能列常常需要重新组织构成它的一些数据字段，这样数据库就将它们作为单独的元素进行处理。

• 害怕变化。如果你害怕改动你的数据库Schema,因为你担心会破坏什么东西–例如，50个访问该数据库的应用–那么这就是一个很明确的信号，你需要重构schema。害怕变化本身就很好地说明了你在冒很严重的技术风险，这种情况会随时间的推移而变得更糟。

重要的一点是要理解，仅仅因为存在某种味道，并不表明它坏了–limburger干酪即使在最好的状态下也有味道。但是，如果牛奶闻起来味道不对，你就知道它坏了。如果存在某味道，就观察它，思考它，如果重构有意义就进行重构。