也谈应用之“基石”——数据库设计

对IT人员来说，“数据库设计”这个词并不陌生，很多人也觉得是个很简单的事情，认为就是建表加字段的工作。其实不然，真正要做好这件事，也许并不是大家都想象的那样简单。首先，我们必须重视数据库设计，对任何应用来说，数据库设计是基石，基石必须合理、稳固，如果不合理，短期内也许不会发现问题，但迟早会出问题；如果不稳固，数据库设计总是改来改去，也会给今后的应用和维护带来很大的困扰；其次，一个能做好数据库设计的称职人员，必须有着丰富的应用研发和数据库管理的经验，因为数据库除了是应用的基石，还是应用和数据之间的纽带和桥梁；最后，数据库设计人员除了精通研发和数据库管理，还需要熟悉应用需求，这点设计人员熟悉最好，否则，通过和应用分析人员很好的沟通，也可以达到很好的设计目标。

前面我们对数据库设计的重要性和相关因素进行了说明，看起来有些抽象和笼统，那么，下面我们就具体的说一下数据库设计需要考虑的因素，通过学习这些因素，大家也许会理解刚才说到的一些方面，例如：为什么设计人员需要研发和数据库管理的经验，为什么数据库设计不合理会引发后续的一系列问题，为什么设计人员需要熟悉应用需求等等。

1、需要涵盖应用需要的所有内容：也就说，应用需要的信息，在数据库里都可以找到，大家看到这里，也许觉得有点废话，但现实中，不符合这条的情况比比皆是，今天加个表，明天加个字段，数据库变，就会导致应用很多地方也得跟这变，应用变，就会带来一些列的问题，也会导致人力和财力上的巨大消耗，这是必然的，也许有的同学会说，我可以通过视图去隔离这些变化，这在学习或者测试时，也许是个好办法，但在实际的、复杂的应用中，也许是个大忌，过多的、不必要的、复杂的视图，也许会带来意想不到的麻烦。因此，我们在做数据库设计前，必须充分做好全面的需求分析，需求必须做透、做细，起码的有个规划，力争在规划期内，不动或者尽量少动作为基石的数据库设计，这样，应用才能更加可靠、平稳、安全的运行；

2、需求所需内容的拆分和合并：说白了，既然应用需要的内容我们明确了（见第一点内容），也就是根据需要存储的数据内容，要在数据库里设计多少张表，每张表设计多少个字段等。也许很多同学觉得这个很简单，可以想怎么设计就怎么设计，跟着感觉走，事实上，很多系统的数据库设计也是这么做的。但是，如果这样随便的设计，就会为将来的应用留下隐患，这方面的设计还是有些学问的，这也就涉及到我们常说的数据库的范式，范式级别越高，数据的冗余越小，数据的存储也就越散，设计出的表数目越多，因此，在应用使用时，就会有越多的表间的连接，我们知道，表的连接会消耗掉很多资源，尤其是内存和计算资源，当然，也会导致IO资源的额外消耗；相反，范式越低，数据的冗余就会越多，数据存储的就越集中，设计出的表数就会越少，这样会减少表之间的连接，但如果走向另一个极端，那就是数据冗余导致的存储空间的浪费，应用在使用时也会消耗很多资源，尤其是IO资源的消耗，从而也导致内存和计算资源的消耗，此外，还会涉及到锁资源的冲突，毕竟，RDB数据的存储还是行存储的。那么，我们怎么才能恰当的设计，以充分利用资源，避免资源的过多消耗呢？那就是根据应用具体需求，折中和权衡，对数据内容进行合理的拆分和合并，注意，需求是设计的根本，它会贯穿设计的方方面面及整个生命周期；

3、表的数据量及数据增量：这点主要涉及三个方面，一方面就是表是否需要分区，如果分区，根据表大小及数据增量，确定分区的粒度，一般来说，大多数需要分区的大表的数据都是随时间而逐渐增大的，这样，就可以根据数据增长的速度来确定分区的维度及粒度，例如：根据时间维的月分区表、天分区表等，但有时，分区表的数据不是随时间增长的，这样，分区的维度和粒度的确定就得看具体需求，这样的表不是很多见；第二个方面，会涉及到存储的设计，有些数据库的物理存储分配单位是可调的，例如：oracle的extent，可以人为设置，这时，就可以根据表的大小及增量，合理设置表的extent，以避免存储空间的过度碎片和空间浪费，尤其是对包含很多小分区的表，不合理的extent设置对空间的浪费是很惊人的，为什么呢？大家可以自己思考下这个问题；第三方面，会涉及到索引的设计，大表和小表的索引需求、索引类型是不一样的，这点还得需要结合具体的需求，这里不再赘述；

4、如何使用数据：也就是，打算怎么来使用和操作这些数据，这就是语句级的需求，这才是最具体的需求，也是最重要的，前面也已经提到，它涉及到数据库设计的方方面面、时时刻刻，所有的一切，最终都围绕具体需求。由于这点几乎影响整个数据库设计，我只能根据特定一、两个方面来举例说明，例如：分区，我们会根据具体的操作语句，确定分区键，以使得分区剪裁生效；同时，我们还可以根据具体语句评估结果集的大小，确定某些字段上是否需要建立索引，建立什么类型的索引；此外，根据这点，我们还可以确定表和分区的存储分配单位和数据块大小等；再如：我们可以根据语句的操作类型，来确定表的拆分和合并，不同的操作类型，要求是不一样的，dml语句需要对数据行加锁，这时我们需要考虑每行数据内容太多，可能造成的锁冲突，必须尽量将可能冲突的数据内容进行合理拆分，以把这种冲突降到最低；另外，如果操作类型是select，那么，语句涉及到的数据内容，也是我们设计表的拆分和合并的参考因素。当然，这里只是举例进行了简单阐述。

5、字段的具体值：在拿到具体的数据操作语句后，我们有时需要考虑某些字段的具体值，根据这些信息，可以确定是否有必要建立索引，以及建立索引的类型等；

总之，数据库设计的学问很多，会涉及数据库的方方面面，我们必须尽量获取更多的信息，并对这些信息进行综合、全面分析和考虑，只有这样，才有可能做好这项工作。对数据库和应用需求掌握的程度，会直接影响到数据库设计的质量，当然，最终也决定应用的质量。在应用数据库时，只有深刻的理解其内部机制，并结合丰富的实践经验，我们才能像数据库一样思考和处理问题，从而做到扬长避短，达到最优效果，禁止转载。