这是数据库架构师Brian Walker关于数据库设计方面系列文章的第二部分。他写这一系列的文章是受到最近一些SQL Server销售店情况的启发。最终，他提出了一些关于改善数据库设计以及SQL Server性能的建议。

　　发生了什么：滚雪球效应

　　那么，事物数据库是如何处在一个糟糕的环境中的呢？一些数据库一开始就处在这样的状态中。仔细考虑一下，他们有的是会计绘制的Excel表格，或者是一些销售商组装电脑的Access数据库。增加大量的数据后，他们就有可能以原来的格式被迁移到了SQL Server。这种解决方案在真正的服务器上能够广泛使用时，更多的人就开始使用这些数据库了。最后，业务就依靠这些混合型的数据库进行。

　　一旦业务依赖其中的一个数据库，集合里的数据就不断上涨，更多的应用程序都会利用这一数据库。拥有二流的数据库技术或SQL的应用开发人员会根据他们的主观意愿在数据库中增加一些表和其他的东西。没有人会调整数据库的扩展速度，他们只在乎通过数据库能够完成什么任务。在数据库性能出现问题时，就雇佣一名DBA。DBA自然会推荐一台力量更强大的服务器。DBA随后设置了一些存储程序并且增加许多索引。性能改善之后，业务自然就继续开展。

　　当数据库开始扩展并增加一系列应用程序的时候，DBA正忙于尝试解决数据库的性能问题。他/她建议用更多的服务器和数据库的副本将数据库负载分开。另一名DBA监控服务器的操作。数据库扩展持续了好几年的时间，现在业务就完全依赖数据库了。有了好几台强大的服务器就能尽可能地分开负载，DBA团队总是不停地在进行战斗，但是还是会出现一些数据库性能问题。

　　最后，DBA团队承认一些性能问题可能是由数据库设计自身引起的。他们接着就提出了“最佳实践”。但是最佳实践太少也提出得太迟了！DBA团队和应用程序开发人员对数据库设计所负的责任并不一样。修补设计漏洞也需要对应用程序密码修改。否则业务就不授予他们权限。这样混合数据库就不会再改变了。

　　避免出现问题

　　你的公司是不是也处在上面几点中的某一个过程中？我希望没有。我希望你的公司能够以正确的方式做事情。有很多方式可以避免膨胀循环以及性能问题，即避免混合数据库让业务无法进行下去的问题。

　　从一开始就建立牢固的数据库基础。从开始的Excel/Access工具中找出业务逻辑、让一名有经验的数据库开发员在合适的关系数据库框架里安装。

　　有经验的数据库开发员能够规范表、建立一个标准的表结构，安装完整的DRI、创建基本索引、选择合适的数据类型以及定义有用的自定环境。如果这些事情在前面已经做完了，那么之后的业务就会有所回报。

　　应用程序开发人员能更有效地使数据库更合理地扩展，如能够简单快速存档和清除。合理设计的数据库很难受到性能问题的影响。他们可能会更加有效地支持数据数量的增长或者应用程序和用户的增加（或者两者皆可）。

　　不要假设一般的DBA就是数据库开发员。他们不是同一个概念。他们的工作有一些地方相同，但是需要不同的技巧。

　　一般可以理解为有两种数据库管理员——产品数据库管理员和研发数据库管理员。但是对每种数据库管理员的定义都不是一样的。如果不同之处仅仅是他们的环境（产品或者研发），那就没有必要把他们区分开来了。

　　我有一个建议可以作出很清楚的区别：产品DBA就是关心数据库以外所有使用问题。而研发DBA（数据库开发人员）关心的是数据库里面的所有事情。

　　一名产品DBA认为数据库是他所关注的最小的项目。研发DBA处理数据模式、规范化、表结构、DRI、索引、数据类型、命名约定、触发器、存储程序、视图、函数、密码生成、数据导入/导出、归档、清除以及审计。他们主要关注的对象就是一个数据库或者是一系列的数据库。研发DBA（数据库开发员）必须懂得业务是如何运作的。

　　正确方法：产品DBA和研发DBA

　　业务世界里这两种DBA的存在很有必要。然而，如果在数据库项目的早期阶段就牵涉到开发DBA，那数据库就会更加强大，服务器硬件就更加省钱，产品DBA要解决的问题就更少了。

　　工作记录并没有显示业务会以正确的方式进行运作。他们仍然在寻找只有二流数据库技术或SQL技术的应用程序开发人员，也仍然在寻找产品DBA来解决这些问题。而对于研发DBA来说机会很少。

　　我担心这意味着业务数据库一开始就是混合数据库。这样他们创造的这种糟糕的条件会危害到以后的业务。

　　我的工作经常就是产品DBA或者应用程序开发人员，但是我喜欢成为开发DBA（数据库开发人员）。