数据库的使用是一门综合的科学

最近思索数据库在使用中有什么问题，数据库到底在应用程序设计起到什么作用。

举例早期以ORACLE 为主的数据库的软件设计主要是以数据库计算为主体的设计思路，这样的软件不少，大部分程序主要是调用存储过程的方式来解决复杂的业务逻辑，完成整体应用的功能。这样的设计方式好的地方，软件开发速度快，易于修改，对于灵活多变的业务和复杂的业务有比较好的适应性。

不好的地方也是显而易见，由于大部分软件的执行代码都在存储过程中实现，则数据库成为性能的焦点，由于存储过程在数据库的特性，导致数据过于集中，并且无法进行灵活的数据分布式存储和应用。所以这样的设计的软件，只能在数据库层面进行纵向的硬件升级和单纯的存储过程的优化，所以适合业务量不大的场景。

以上的开发方式，在互联网高并发的访问模式下，已经荡然无存，高并发访问模式下的系统主要考虑的是扩展性，有了扩展性高并发访问进行分散访问，逻辑上考虑是不会有什么性能问题的。其实说到头，还是要扩展，无论是纵向扩展还是横向扩展。横向扩展看上去很美，尤其MYSQL的分表，将一个表分散到不同的物理服务器上，数据的承载力和并发访问能力的提高都是有目共睹的。

这里问一句，这样的方式是应该在哪种场景下都应该被推广的吗？

回答是NO， WHY

这样的软件架构设计，和数据库的架构设计上都会比较复杂，复杂就会带来成本和维护成本的问题。如一个应用只有一个数据库，那维护的成本是多少， 如果一个应用有 N个数据库为了弥补某些数据库本身的缺陷，那维护的成本是多少。技术提高最终是要为业务服务，不能因为提高技术而提高技术，高层可能根本不CARE 你底层的数据库是 POSTGRESQL 还是MYSQL，如果此时ORACLE 免费那么估计能继续用ORACLE 也说不准。

所以一项技术最大的卖点是成本，你节省了什么成本，你最大化满足了业务的需求，用一套难于维护，难于使用，来说明你解决问题的能力，这样的解决方案不是最优的。提到数据库中的一个例子不得不让人想起，分库分表，尤其是分表。

分库分表是什么时候兴起的的，毫无疑问MYSQL 导致的分库分表，你何时听说过 ORACLE SQL SERVER 去分库分表，因为他们在性能方面满足了一般大概率的性能和应用场景，单库就可以满足。

MYSQL 本身单库是无法满足达到, ORACLE ,SQL SERVER ,PG 的水平，那为什么有的应用一提到分库分表，就兴高采烈，或许复杂的结构更容易让技术人员的荷尔蒙升高。这导致大厂的一些开发的经验到了一般企业，无法发挥作用的一个原因，他们在设计之初考虑的问题的重点是性能，而非更易于成型。而没有去大厂的程序思维，大多是以业务逻辑成型为主导的程序思维模式。

没有哪个更好，最终都以支撑业务为目的，谁更便于维护，更便宜，成本更低，则对于公司的利益来说，他就是当前最好的选择。

数据库与软件架构的设计，会导致后面程序好用不好用，数据库性能出不出问题，都是前期设计定下的，并且和你的硬件水平，等等都有的关系，光弄懂数据库，或者光弄懂程序架构设计，或许都不是特别难的事情，而要明确这些东西之间的关系，如何互相协同，或者互相妥协才是一门科学。

数据库的使用应该是一门综合的学科，光考虑数据库本身不去了解数据库本身承载的业务， 以及承载数据库的系统软件和硬件，会陷入自己的小圈子。如

数据库的各种推出的IOPS以及性能指标 ,但压测出的数据与实际的情况大相径庭，如同你买汽车的时候，工信部的油耗你相信吗？

每个数据库单独拿出来进行评测都是棒棒哒，但只要放到实际应用中，就会毛病和问题，这或许和人生差不多，每个人自己活着的时候，都觉得自己挺好，但你把他放到复杂的应用系统中，那就有很多种的“化学”的变化了。