软件设计中的天灾和解决方案.docVIP

软件设计中的天灾和解决方案 （DB结构发生变动） ——荣少 在自主研发项目中很多情况下由于先前的设计考虑不周或者开发者和设计者的沟通不够就会发生在项目进入尾声阶段的时候数据DB发生了变动。无可否认这的确是一个天灾。任何开发员都知道，在项目中期和为期的时候如果改动DB结构将会发生一系列的连锁反应，即时你的项目中运用了设计模式等方式来降低耦合度。但是对于DB的修改所造成的反应将是很验证的，至少会在很大程度上影响项目的开发速度。 以前在网上看到关于表继承的说法。就是说如果出现这种问题，为了保证原有表不发生变动所以添加附表用主键进行关联。是的这种方式的确可以在很大程度上减少项目由于DB结构的改变所发生的不可预估的错误。但是如果添加附表就意味着外连接，子查询这些操作，即使你使用存储过程操作但是这个问题依旧。所以项目的整体运行效率降低将是基本上不容忽视的。也可以这样说这种做法是以牺牲程序性能为代价换取开发时间。 如果既要保持项目的开发时间不会为此被牵扯，但是性能又不能有较大的降低的话这个地方该如何解决呢？答案就是缓存机制。 首先在上述的解决方案中添加附表的做法是可行的，即使在开闭原则面前它也是最符合的解决方案。但是弊端是在于子查和外链的时候性能的消耗。所以我们要解决的问题就是如何提高添加附表后的性能消耗问题。 第一：我们的性能消耗问题出现在哪里 在解决之前我们首先要分析我们的性能消耗的问题出现在什么地方。我们在添加了附表以后主表和附表之间通过主外键形成了表关系。但是在我们操作的时候这两个表之间肯定要进行子查询和外链查询。这两种查询方式和我们之前对单表查询的方式效率肯定不在同一个等次上，即使你是用了存储过程来对你的语句进行预编译也是如此。跨表就是比单表慢。 第二：解决方案 那如果我的用户不用读取数据库呢？这样的不就不会出现这个问题吗？是的还有一种方法就是不读数据库，正确的来说是降低数据库的读取次数。让数据达成公用。所以在这我提出的方案是当应用程序启动的时候将数据全部查询组装好然后放入内存中形成一个对象，每次数据的有关查询直接在内存中进行操作。这样我们不仅可以降低用户每次操作时表关系造成的性能消耗并且还可以降低用户每次连接数据库的时候打开关闭数据连接的性能占用。 第三：后续问题 1：如果采用这种方式的话，如何保证缓存中数据不会产生脏数据呢？ 答：这个问题在设计方案的时候并没有没考虑进去，因为在方案建立的时候索缓存的数据均为基本数据非业务数据，所以只有查询的操作。 2：采用这种方式缓存是否会造成服务器内存的消耗？ 答：内存消耗肯定是有的，但是如果按照1G内存来说的话我们将能放进去多少数据？所以这个问题是基本不存在的。 Thursday, April 02, 2009