数据库味道

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干酪即使在最好的状态下也有味道。但是,如果牛奶闻起来味道不对,你就知道它坏了。如果存在某味道,就观察它,思考它,如果重构有意义就进行重构。

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号