接触数据库这么多年，这个问题也被问了无数遍。

做过很多数据库模型设计，最近的两次:

一次是设计了四百来张表的系统，整个系统的脚本统一xml管理，其中90%的脚本都出自我手。

另一次是设计了200来张表的系统，整个团队的能力很强，我只是出了几个脚本的模板。

关于写脚本，概括起来也就三点：基础知识、业务知识、逻辑思维

基础知识

是指掌握的数据库基础理论知识，以Oracle数据库来说，包括数据库的体系架构、系统视图、常用函数、分析函数、正则表达式、隐式转换、空值理论等。

熟悉这些基础理论知识，能让你写出来的脚本简洁、漂亮，一定程度上提升脚本的性能

业务知识

是指底层的数据架构，数据对接的业务含义。数据架构不仅要了解整个系统的表架构、每张表的主键、表之间的关系、字段的含义与约束，还要了解数据在各个表之间的流转，以及，实际存放的数据是怎样的。

逻辑思维能力

就是考验你能不能在脑海中把各个表之间的关联关系画出来，针对业务需求去构建实现方法(其实不止是sql脚本、java语言、hadoop技术道理都是一样的)

谈完理论，接下来说说实践。

拿到一个功能或者提数的需求之后，怎么写sql？

跟写java代码一样：需求分析、设计、开发、测试。

不一样的是，做事的方式略有不同。

1、需求分析第一要搞清楚功能或者提数的目标，或者说你做这件事的意义何在。

很多需求拿到手的时候，只是非常简单的几个字。对方提需求的时候并不了解系统多复杂，也不关心你实现多麻烦，需求提出人的要求很简单，你把我要的东西给我就成了。

要的是什么？不就这几点嘛，这你都看不明白？

接下来做需求分析，就要搞清楚对方到底要什么，已什么样的展现形式提供更合适。谈话过程中你要结合你了解的系统功能，你了解的业务知识，准确夯定对方要表达的内容，落实成为可以从系统中获取到的东西。

如果你接触过的展现形式多，那就可以在谈需求时给对方多一些选择，尽量提供一些与对方目标偏离比较小、又能节省很多开发工作量的方案。

2、设计

写脚本的设计，与java开发的设计方式是完全迥异的，前段时间也有幸听到另一位仁兄提到过。

写脚本，第一你要清楚所需要的数据可以从哪些表(集合)中获取，表之间如何关联。

第二，希望你大学里学的集合的概念、集合运算的公理、定理还记得，如果记得，能更好的梳理思路。甚至思路不清晰的时候把他们抽象成集合，运用集合的理论去简化、验证。

第三，你要熟悉各种理论上的注意事项，比如空值，not

in会出错，为什么会出错呢？比如偷懒字符串相等不加单引号有时报错有时不报错，原因是什么？比如过滤条件加在where、join、having上的区别是什么?对效率和执行结果分别有什么影响？

3、开发

基础牢固、思路清晰、目标明确的话，开发真的是简单的不能再简单了。最近有位同事跟我一起做开发，应该深有体会，他做了一周，没做对，我做了半天，告诉他，这就是我需要的结果。

4、测试

很多人都不会测试，写完了就写完了，最多重新审一下逻辑。

正向来讲

写完一个提数脚本，最起码要确认出来的总数据量是跟期望的一样的，如果你还不清楚你的期望值，那你该好好检讨。

确认完总量，就需要检查每一列的内容，检查最基础的，要做一下group by，看看都有什么内容，分别多少条。

第三步，就是抽查，或者根据别人的成果核对。抽查就是抽单个人的记录，出来的结果是不是跟系统中的实际情况相符。

反向来讲

开发一个功能，会有各种各样的异常导致你的数据出问题。

比如，数据库中没加限制，该列可以为空，如果为空，你的程序会不会报错？

比如，入参、出参的某个参数的长度超长，输入内容超出限定范围，你的程序能不能返回友好的提示？

比如，计算量太大时，你的程序执行会怎样处理？你的计算量上限是多少？有没有跟其他人统一约定？

针对测试的经验之谈：不要只在最后一步做集成测试，把你的工作拆分成一项项逻辑简单、容易掌控、容易验证的脚本。

啰啰嗦嗦写了这么多，都是一些大白话。如果你觉得看了完全没概念，那么只能说你在数据库方面的实践经验太少。如果你觉得写的太基础，那应该是前辈了。。。

sunseawind原创，如果你喜欢，转载请注明出处。