企业级N Tier体系结构解决方案讨论
--NT+SQL Server plantform篇
Writen by pepper_dog999
    关于企业级的数据库结合前台应用程序的解决方案现在成为了整个网络应用的热点问题。很多企业在选择解决的方案
时常会考虑的问题可以归结为三个h，即High performance、High security、High transaction solution。我的这篇文章
意在比较业界流行的几种解决方案之间的优缺点和可行性，本篇讨论的是微软的解决方案。
首先我们在这里不去讨论常规的Server/Client模式，也就是2-Tier模式，虽然这种模式的应用最为广泛，但由于对于企业
级的需求来说，这种模式的performance和security都不能达到要求，所以我们主要讨论的是N>=3 的情况，也就是
Database Server/Application Server/Client的模式。至于Distribution Transaction的情况我们暂时不做讨论。
在这里我首先提出我的一个看法，那就是现在大部分的方案开发者都走入了一个误区，那就是将工作的重点和大部分的精
力放在了3-tier体系结构中的第二层，也就是App Server上，由于整个业界不断的推出新的中间层解决方案，从perl到asp
到php到isapi到现在的jsp，所以开发者的大部分时间和精力都用来熟悉新的解决方案和对比各种方案的优缺点上。诚然，
好的中间层解决方案能够提供更高的性能和安全性，也就是前面三h中的前两个。但是这是在小量数据的时候(tiny
data)，那么当大量或者是海量数据出现的时候呢？这里我想借用硬件中常用的一个术语--瓶颈(bottle neck)，大家都知
道瓶颈是制约整个体系的最慢的部分，当海量数据出现时，整个3 Tier体系中的瓶颈就成了该体系中的第一层，即
database Server，而在企业级应用中，我想可能以第二种情况为多。大概二者性能影响的比例应该为4：1吧，而且数据量
越大这个比例也就越大了，这也是数据库产品的售价远高于应用程序的原因吧（笑）。现在较高级的数据库产品如SQL
Server、Oracle等都将Autentication、Performance、Transaction紧密的结合在了它们的产品中，那我们的开发重点是否
也应该相应的放在database Server端呢？而在app Server端只是几个简单的调用过程和参数的传递过程，那么app Server
端用哪一种方案就不再是一个很重要的问题了。我觉得是越简单越好，为什么不呢？非要去用isapi吗？这样的话开发的重
点不就本末倒置了吗？如果从开发成本/性能效益的角度来分析的话，那就大大的不值得了。所以我觉得与其将大量的精力
放在前台的app Server上，不如将更多的工作重点放在后台数据库的设计、开发上，将核心的处理过程都转移到database
Server上。将精力用在数据库的合理设计，数据库中实体之间的关系，索引的合理配给等方面。例如2NF、3NF的实现哪，
表中仄余column的分析上啊。我的几位同学都在做这样的项目，他们的程序不能说不好，所用的技术也是日新月异，可他
们数据库的设计可就实在不怎么样了。各个表之间的关系混乱、大量的仄余column，我想这可能是因为他们没有从一个总
体的角度去考虑问题吧，而且一个整体的解决方案需要对各个层次都有所了解，这也是不太容易达到的了。周星弛在大话
西游中说"

[1] [2] [3] 下一页

在google里搜索更多企业级N Tier体系结构解决方案讨论(二）

	Web www.51ec.org

上一篇信息学院： 企业级N Tier体系结构解决方案讨论(一)…

下一篇信息学院： 纯ASP上传图像文件到数据库的最佳例子