做MIS测试和维护的时候，我经常和别人说：看数据说话，数据会告诉你想知道的一切。
想对数据有个深层次的理解，有2点因素要考虑
第一点：数据所代表的业务领域
第二点：用来存储数据的结构
对于第一点，我想大家都没有异议，做MIS，做着做着，大部分人最后都去玩业务了。我们重点谈第二点。这些年我已经习惯在做需求的时候画界面原型，即使没有界面，我也会把客户需要知道的结果给写出来，这是我做这个系列文章中一直在推荐的方法，在特定场景下写写文档好处多多。好吧，下面我们来看看需求是怎么演变成存储结构的：
1、首先，和客户在系统实现的业务认知层面上没有歧义，客户见到的就是我们要实现出来的东西。这一步解决了用例和用例描述。
2、然后，根据所写的需求说明书，模拟客户做个用户体验，就可以把FORM找出来。
3、其次，FORM一找出来，基本上就知道数据库要保存什么数据以及它们大概的结构。
4、再次，根据非功能性需求的要求，开始调整结构，让结构更合理，维护起来更舒服，性能更适合。在这一步更多的是依靠经验，存储结构会有两种思路来调整：
第一种，如果采用的架构有O/R层，如Hibernate，就要从对象的角度来思考数据存储结构。以前我想把一个C/S的程序移植到JAVA 的B/S上，初期打算跟潮流使用Hibernate，但做的过程太痛苦了，最终我放弃，无它，就是以前设计的存储结构太随意,基本上业务实现都是靠存储过程，在套用Hibernate思想时等于要重新架构数据存储结构和业务处理模式。
第二种，原生态的关系型数据库存储结构。这个相对好处理一些，从维护的角度上个人比较喜欢做一些冗余字段，喜欢使用存储过程处理业务。在初期甚至在性能上都可以不用太多的考虑，按个人经验，升级硬件比程序性能调优简单多了，等到硬件升无可升的地步，再认真考虑程序优化，这时候你的客户如果还在使用你的系统，那么我可以大声的恭喜你，你做的很成功，客户对你很依赖。我不是说什么都不要去考虑，只是优先级会低一些，常用的如索引、分区等等还是需要在建模的时候就加上去。
5、最后，表结构的数目会随着业务和时间越变越多，因此建议大家使用诸如PowerDesigner之类的建模工具，数据库设计报告可以通过工具导出来。身边有不少人玩数据库的不爱用，很无语，我承认他们都很牛，但是还是要给别人一条后路。在IT职场上，吃编程饭的人并不是每次都是做新系统，还有很多老系统需要维护，没需求文档，认了，多接触业务也就明白了，没设计文档，认了，代码看看也就熟悉了。如果表结构还要从生产数据库中逆向工程导出来，那就杯具了，一个是，字段含义不一定能猜的到，另外一个是，谁知道当时这个字段有没有什么特殊约定。
有了建模工具我们就好办了，它可以给我们很多的帮助，至少在开发的时候我们很明确，看图说话都容易明白。在后期维护中，注意要同步更新，这可以让我们遗忘后，不需要花太多的精力在猜上面就能查的到。有了这保证，我想数据会告诉你想知道的一切。
