谈谈数据库的水平划分(2)

 5、说到这里要说一下应用设计开发上的问题，首先是对目标数据库表路由模块必须要独立，如果路由不独立出来，那以后万一路由策略变更的话会死的很惨，而且路由算法是一个典型的策略模式应用，最好能实现成策略模式，以方便以后路由策略变更时应用可以无缝的切换路由策略。其次是对开发来说，最好能使用ibatis之类的持久层，既有一定的封装，也可以将SQL独立配置，这样在开发人员开发时，可以灵活的写SQL来实现逻辑，也可以对SQL语句进行管理，同时DBA可以很方便的对这些SQL进行专业的优化，而与应用开发无关。现在一些先行者已经在努力实现将数据库拆分的影响封装在代理中的项目，比如变形虫项目，这些项目的出现将会使数据库拆分后对应用开发的影响越来越小。最后一个是事务，如果可以接受分布式事务的性能那当然是最好的；如果不能接受，那一般的做法就是事务补偿（指在同一业务操作中当事务A提交，但事务B发生错误回滚后，为保持操作一致性和数据正确性，必须要做事务A操作的反操作来补偿事务A的提交，消除事务A的提交对数据结果的影响），但事务补偿会增加开发的工作量等问题；或者不是非常重要的业务操作时，通过保证事务B执行的成功率（比如先进行查询或预执行操作），从而使事务B的失败率下降到可以忽略的程度，从而可以不考虑事务的问题。

        6、还有一个非常重要的需要说一下，一般来说很多都是对原有系统的改造，这样的话就必然会有需要对原有数据的处理割接，这块工作也是非常重要的，数据库拆分方案做得最好，如果原有数据不能无缝的割接到新的拆分后的数据库中的话，那都是白搭。另外还有业务层面的问题，比如数据库表拆分引起的业务流程更改，业务操作习惯更改等方面的问题也要提早考虑和解决。

        总之，数据库表水平拆分是非常复杂的，需要综合各个方面考虑完善，套用网友cauherk的说法“系统的切分是个很复杂的技术活，要综合考虑，而不仅仅从数据库层面考虑。 业务的使用、分库的原则、数据的割接、开发的侵入、可操作的易难程度、后期的管理等等都是需要考虑的因素。”。