企业级N Tier体系结构解决方案讨论(二)(1) 企业级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，我想这可能是因为他们没有从一个总体的角度去考虑问题吧，而且一个整体的解决方案需要对各个层次都有所了解，这也是不太容易达到的了。周星弛在大话西游中说"斗鸡眼其实与常人没什么不同，只是看事物的方法不同罢了，是将视线和注意力放在事物的某一点罢了。"但我们在项目的总体开发上却不能这样，要不然对项目的可行性分析和总体的考虑还有什么意义呢？前面我说的我的那几位同 学他们的后台数据库也多是SQL Server和Oracle。但他们并没有去发挥这些产品的特性。比如说他们在SQL Server上建立了一个员工的信息数据库，其中有一个表(member_info)用于保存员工的信息。为了获得该表的数据他们在app Server端写了如下的语句： conn.ConnectionString="Driver={SQL Server};Server=sev1;uid=user_name;
