漫谈数据库的中庸思想

2019-11-18 12:11:37

字体：大中小

来源：转载

供稿：网友

　　想写一篇关于数据库的文章，这个念头已在脑海里晃了一年多了，之所以迟迟没有下笔，主要是好多想法还不够成熟，需要更多的酝酿，再者很多年没有写过什么东西，在文笔上也是缺乏信心。掐指一算自己做数据库的设计或治理也有四五年的时间了，总还是有一些心得，今日拿起笔来也就一吐为快吧。
　　早在几千年前，中国古代的大思想家孔圣人就曾说：“不偏之谓中；不易之谓庸。”后又有《中庸》解释说：“中者，天下之正道；庸者，天下之定理。”到底该如何理解中庸呢，
　　也许只有那些研究儒学的大家们才可以给出一个确切的解释，在此我们姑且不去细究。但将中庸的思想运用到我们的生活和工作中，我们可以有自己的理解，那就是适度、有节之谓“中”；当变则变、不当变则持之则谓“和”。因为中之，万物则兴也；因为和之，万物则久远。你看我说得是不是太大了，不过也没关系，既然是漫谈，那就随意、自然一点好了。
　　既然万事万物都遵循中庸的道理，那当然我们的数据库也就不会例外了。一个有数据库参与的项目、从开始的业务调研、流程分析、到数据的概念模型设计、数据库逻辑结构设计、物理结构设计、项目实施、数据库的治理等各个阶段无不要持有一种中庸的思想，才可以保证项目的成功实施，并保证系统具有强大的生命力。其实不管是数据库的设计、开发、还是治理都是充分、合理、恰当的分配使用现有资源，是其有效的组合、构成一个系统，在其运作起来时，达到一种理想的效益产出。而其中的“充分、合理、恰当”无不是一种度的把握和中庸思想的体现。而这种度的斟酌，则是为了寻找到一个又一个平衡点，去适应一种简单或复杂的现实的需求，这就是我们所说的“中”；而值得注重的是，这个平衡点又是动态的，它将随着外部环境的变化或（和）内部因素的改变而需要得到相应的调整，这就是我们所说的“和”。
　　数据库的设计和治理的任务其实就是调和现实业务和构建系统之间的矛盾而实现一种需求。所谓“知己知彼，百战不殆”，就要求我们首先对业务有一个透彻的学习、调研、甚至是调整。因为我们讨论的是数据库中的中庸思想，所以我们姑且认为在开发数据库的应用之前，我们已经对业务及需求有了一个详尽的了解和全面、彻底的理解。
　　以Oracle数据库为例，其中不仅有着应对各种不同需求的对象部件或技术策略，更有着成千上万的可调整的参数或配置，即使现实的需求是千变万化的，只要我们使用、配置得当，就能构造出运行良好的数据库应用系统。这就象修房盖屋，ORACLE为我们预备了大大小小、各具用途的材料，也预备了锯子锤子等各式工具，而我们就是使用合适的工具把合适的材料裁成合适的外形和合适的大小，使其组合起来形成一套舒适、耐用、又漂亮的房子。而其中处处提及的“合适”与否则依靠于我们的经验、前期的工作、及对数据库的理解等等。
　　谈到数据库的应用，我们首先想到的可能就是用数据库来存放数据，存放到数据库的表里，而ORACLE单是表类型就有几种，如：堆组织表，也是最常用的一种表，还有索引组织表，索引聚簇表、散列聚簇表、嵌套表、临时表。每种表都有它特定的性质和特定的用途，当用才用，否则就会适得其反。
　　当谈到数据库的性能时，人们最先想到的可能就是索引。而索引是不是总是可以提高性能，回答是“不一定”。有人比喻索引就象“盐”，加少了“菜”不够味、加多了就太咸了。事实上还远没有这么简单，就是“盐”，也有很多种，如：二叉树索引、位图索引、函数索引。每种“盐”都有其使用范围，适用的应用类型、适用的度。超出了范围、超出了度，就会失去平衡。失去小的平衡，系统运行不畅，失去大的平衡则会导致系统崩溃。
　　讲到这里，我们明白了在数据库中要把握一种平衡，并且是一种动态的平衡，只所以是动态的，因为时间在流逝，很多数据库外在或内在的因素在改变，让平衡保持静态等于失去平衡，所以原本平衡的东西需要进一步调整达到一种的新的平衡。
　　如若我们把上面的动态平衡作为一种纵向考虑，其中的时间可以看做其变化因子，那么我们还要做一种横向的考虑，空间可以作为其变化因子，那就是要注重局部的平衡与整体的平衡。局部与整体不是绝对的，而是相对的，如数据库服务器相对与其中的内存、外存、CPU，它是一个整体的概念，但若放到一个网络环境中，它则变成了一个局部概念，数据库系统相对于其中的各种对象，如表、索引、视图、包、过程、函数等它是一个整体的概念，但若放在一套完整的数据库软件系统中，其中可能有各种协议、应用层和客户层的软件，它又变成了一个局部的概念。其实也可以认为一个大的系统是由很多小的系统组成的，我们就是要学会用系统的观点去看问题，在局部的系统中的把握平衡，而又注重到局部系统之间的平衡。如下图所示：
　　
　　
　　再举个例子来讲，在进行数据库的设计与开发是，我们的设计和开发一般都运行在数据库服务器上，所使用的可见资源无非就是CPU、内存、外存磁盘之类，而在这几种资源中，磁盘是相对短缺的资源，因为磁盘IO是最耗时的工作，除了配置磁盘阵列、高速硬盘，把不同类型的数据放到不同的硬盘上，采取一种“分而治之”的策略以外，我们更应该谨慎的是在开发应用时尽量减少磁盘IO，有人以为增大内寸可以减少磁盘的物理IO，这只是一个方面，其实任何一个SQL调整专家都明白要减少SQL执行时的逻辑IO。
　　针对不同的应用类型，有些是耗CPU资源严重、有些是需要大量的磁盘IO，而我们就是要做到对症下药，合理分配资源，使之达到一种平衡，这样才会有最大的效益产出。
　　这是考虑数据库服务器本身，当着我们把它放到一个网络的计算环境时，我们就要考虑在数据库服务器、网络、应用服务器、客户端等组成的一个大系统中保持资源的分配合理，例如分割应用，把一些逻辑运算放到数据库服务器，利用它的强大的计算能力和临近数据库的数据，产生的计算结果也包含了最少量的数据，从而在数据传输时减少了网络压力。当然，采取数据库端编程的好处还不止这么多。
　　还有就是不同资源之间是相通的、负担和压力是可以流动的。在数据库的设计中用空间换取时间就是一个很好的例子。
　　总之，不管是横向的、还是纵向的、我们都要以一种动态的观念、中庸的思想去观察和解决问题。

上一篇：第十三讲：关于.NET组件

下一篇：java数据库的实现