DBA在系统设计、开发中的重要性

核心提示： 底层数据结构不合理由于缺少专业DBA的协助，很多系统设计出来的底层数据库表结构问题重重，DBA在系统设计、开发中的重要性(2)，而做过系统的人都知道，底层数据库结构不合理，也在这些和自己毫不相干的功能中频繁地执行着……同时，对数据流的检查还能够查出一些隐藏得较深

底层数据结构不合理

由于缺少专业DBA的协助，很多系统设计出来的底层数据库表结构问题重重。而做过系统的人都知道，底层数据库结构不合理，带来的改造代价之大几乎等于一次重构!我见过一个OLTP系统，其核心表竟有100个字段，平均一条记录超过8K，如果按Oracle默认的8K一个Block，一半以上的行必须产生行链接!

而最糟糕的是，设计这样表结构的人还认为自己充分利用了冗余来降低表之间的连接，事实上，其人根本不晓得什么是范式、什么是更新异常，按照范式，这个表应该拆分为两个表的，但如果要改几乎所有的程序都要改!虽然范式不是越高越好，但绝对是设计的人必须吃透的一个东西。在冗余上，相信大多数DBA都认为，级联更新的代价是非常高的，因此冗余应当避免发生级联更新的情况，对于关系型数据库设计中冗余的使用，绝不是门很容易掌握的技巧。

不合理的底层数据库结构设计，给系统的性能埋下了重磅的定时炸弹，这个系统在客户那里跑不到一年，数据量稍微上去些，性能、稳定性就直线下降，而重构的成本又极高，买新服务器肯定是只能治标。而假如底层数据表结构是资深DBA设计的又会如何?当然，如果完全让DBA去做数据库表结构的设计，DBA就必须非常清楚地了解整个系统的业务细节信息，这在DBA来说，人力资源上是有一定困难的，毕竟维护好线上服务器就已经占用了DBA很多的资源，并且领导们通常更看重这点。

很少有领导能认识到DBA在系统开发设计中所起到的作用，和维护线上系统、处理DB故障相比，对整个系统的稳定性和性能，是同样重要的!

SQL性能问题

系统的开发，通常和DBA是没有什么关系的，但是，如果DBA对系统有足够的了解，这时候也是可以做不少贡献的。比如，检查系统业务的数据流是否正确，这个需要通过一些手段，比如sqltrace、10046等，详细对系统的逻辑实现进行检查，一方面查出系统中过于消耗资源的或编写不规范的SQL及时进行调整优化，另一方面，查出系统中不合理的数据库访问，不要到了线上才发现问题，那时可能已经宕机了。简单举个例子，当一个页面需要多处显示商品的类目列表时，程序往往容易犯一个错误，就是多次以同样的SQL读取出同样的数据，并应用于每一个列表显示上，如果你只读取一次，或者干脆在Web层进行cache(要有适当的刷新策略)，就可以大大减少单次访问该页面在DB上的I/O消耗。有时甚至会检查出根本不需要被执行的SQL，也在这些和自己毫不相干的功能中频繁地执行着……同时，对数据流的检查还能够查出一些隐藏得较深的系统Bug，这个更需要基于DBA对业务细节的了解。