标签：style 使用 sp 数据 on 问题 bs 时间 as
多年开发和维护某些业务系统的经验，让人真正理解了什么叫“数据库设计良好，系统就成功了一半”，尤其是那些面向多商户的基础服务平台、公共服务平台、开放服务平台、或者由它们组合而成的综合服务平台。数据库设计之初，必须对业务系统DB的隔离和共享模式的优缺有充分的调研，平衡好业务系统的边界，合理设计使用必要的冗余，以适应系统后续的不断变化，否则后期开发人员将陷入无尽的烦恼和痛苦之中，这绝不是危言耸听，只有开发和维护过平台类产品的人才能深刻体会。下面就介绍三种业务系统中最常见的数据库设计的隔离和共享模式：
很多开发人员最熟悉的一种模式，没错，很可能你在大学的时候写的第一个MIS就是用的这种模式。
某些家伙认为这种模式没啥技术含量，但是，如果你的业务系统要兼容很多业务端的需求，当你选择这种模式的时候，用好了并不容易，尤其是当业务数据量非常大而且需求还在不断变化的时候，会有各种各样的问题暴露出来。
下面分析这种共享模式的主要优缺点：
a.前期开发相对容易，单库单表的增删改查，喜闻乐见，注意，我这里说的是前期开发较容易
b.较容易做读写分离、备份和还原
c.能最大化利用DB服务器资源
c.DBA监控和运维管理也非常简单
a.后期开发和维护会非常痛苦，各种复杂业务共享数据库,不同商户业务逻辑的差异很容易引发开发上的BUG，尤其是牵一发而动全身的公共服务系统
b.单库的容量终究有限，不能适应业务数据量的快速增长
c.多商户业务逻辑不一致，表设计时字段冗余不可避免
d.不利于自定义数据模型，可伸缩性受限制
e.无法对业务层进行横向扩展，某些场景下想通过一个库单张表搞定所有业务逻辑，开发人员只能呵呵了
这个也很常见，直接理解就是为每个业务端独立使用各自的数据库，互不干扰。它的优缺点非常明显。
下面分析这种独立模式的主要优缺点：
a.和特定商户业务系统联系更紧密
b.前后期开发和维护都很容易
c.利于业务系统拆分和整合
d.各商户业务数据相对独立，各子系统对其他商户业务系统无影响
e.分流业务系统数据，间接实现了集中数据的分片和纵向扩展
f.性能可能更好，只是可能
a.软硬件成本增加
b.不可避免的重复，主要有重复的数据库设计和业务逻辑，还有独立的后台业务支持系统，总结起来就是一句话，重复的劳动需要更多的人力资源投入
c.DBA管理压力增大，更多的库更多的表需要监控和运维
这种模式是一种设计上的平衡，兼有共享和独立模式的各自主要优点。
下面分析这种兼有共享和独立特性的模式的主要优缺点：
a.虽然是单库，但根据不同商户进行了特殊业务的拆分，减少了冗余的数据库和数据表的设计和开发，性价比更高
b.纵向扩展非常容易，业务拆分更简单，只要将多商户共享和单个商户特定使用的表独立出去就行
a.表设计要求更高，要设计和平衡好有限扩展和无限扩展的可能，否则后续维护会发现还不如完全共享或者完全独立模式来的容易
b.业务数据集中，但表设计分散，后台系统如配置管理系统、统计分析系统很难做到共享模式的便利
总结：上面是最常见的业务系统数据库模式，共享和独立并不矛盾，各有自己特定的优缺点，它们依然属于集中式数据设计和管理的范畴，要按照业务系统的现状来选择模式。当然，后期业务系统的不断发展，数据量日益庞大，集中式的数据模式就会爆发很多问题，横向扩展只是一个时间问题，从数据库设计的角度，横向扩展才是永恒的难题。
标签：style 使用 sp 数据 on 问题 bs 时间 as
原文地址：http://www.cnblogs.com/jeffwongishandsome/p/talk-about-share-isolated-pattern-in-db-design.html
