打造数据库堡垒

作者：丹·恰克（Dan Chak）

所有数据，包括员工输入的数据和从客户那里收集来的数据，都存放在数据库里。用户界面和应用逻辑会变化，业务会发展，人员会变动，但是数据会永远保留下来。所以，创建牢固的数据模型要从第一天开始，这绝非言过其实。

敏捷方法盛行使很多人认为在有需要时才设计应用是可行的，甚至是更可取的。提前展开全面综合技术设计的日子己经成为过去。新派观念提倡尽早地、频繁地部署应用；一行写进产品的代码比头脑中的十行更有价值。这些听起来近乎完善的观点，对数据库却行不通。

尽管业务规则和用户界面经常变化，但是采集来的数据的内部结构和关系通常不会变化。因此，通过正确分析，首先从结构上定义好数据模型非常关键。将数据原封不动地从一种模式迁移到另一种模式是非常困难的，不但耗费时间，而且容易出错。应用层出错还可以暂时忍受，数据库出错则是灾难性的。一旦数据被破坏，即使事后能够修正数据层的设计问题，丢失的数据也无法恢复了。

牢固的数据模型既可以保障当前数据的安全，又为今后提供可靠性。要保障数据安全，就必须隔离来自应用层的Bug（在不断变化的应用层中，这些Bug无处不在，不会因为你的勤奋而消失）；必须严格遵守引用完整性（refrential integrity）规则，尽可能使用域约束（domain constraints）规则；还要选择恰当的键（keys），既保证数据的引用完整性，又遵守约束规则。要实现可扩展性，就必须正确地将数据标准化（normalizing），以便今后在数据模型上添加架构层；千万不要偷懒走捷径。

数据库是保护珍贵数据的最后一道关卡。应用层的设计经常变动，无法保证自身的安全。为了妥善地保护数据库，数据模型的设计必须做到能够拒绝无效数据，阻止无意义的关系。在定义键、外键和域约束时，应该采用简洁的，容易被理解和验证的名称，使它们的含义不言自明（self-documenting）。数据模型中的域规则也要做到物理化和持久化（physical and persistent），避免它们在应用逻辑发生改变时被删除。

为了充分发挥关系数据库的作用——让它真正成为应用的一部分，而不仅仅是存放数据的库房——必须从开始构建数据库时，就深刻地理解业务需求。随着产品的演变，数据层也会发生变化，但无论何时，都要确保数据层像堡垒一样坚固。如果你信任数据层，赋予它捕获其他架构层Bug的重任，它不会让你失望的。