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

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

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

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

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

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

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

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

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

原文地址:https://www.cnblogs.com/lhdz_bj/p/8675383.html