西西河

主题:【原创】SQL 2005 给数据库开发带来的新鲜空气 -- Highway

共:💬7 🌺4
全看分页树展 · 主题 跟帖
家园 大概说来,2-tier的结构有这么几个显著的问题

Scalability, Security and flexibility.

比方说你有一个应用要发布到200台用户的机器上。如果是2-tier结构,每个客户程序都要向datbabase make connection。这样最少需要200个concurrency connection。以前的SQL数据库是按Connection来收费的,200多个connection费用可不低(现在有按Procesor收的,unlimited connection)。

另外200多个Connection对以前的SQL压力不小,性能可能会很不好。如果客户进一步增加,Scalability的问题就明显了。

按照Defensive coding的原则,Connection这种东西最好不要让client拥有。因为我们没有办法control client machine的行为。并且如果Client端make connection的logic被人识破(比如Java反编译),那么别人就可以连到你的数据库上做其他操作。这是非常危险的。

另外如果client拥有connection,那么理论上他就bind在后台的数据库上了,不管是使用Dynamic sql还是stored-procedure。如果后台的数据库系统变了,client就要重新修改,编译,还要重新deploy到用户的计算机上。这可是不小的麻烦。

使用3-tier,这些问题就解决了。client只知道向middle-tier要数据(使用RMI,DCOM或者其他什么技术),middle-tier可以使用connection pool,以几个connection来服务众多的客户,并且connection always open 效率也很高。另外如果后台数据库改了,只需要改动middle-tier,client端程序无需改动。最后,你把business logic都放在middle-tier(一般deploy在server上),安全性有很大提高。

这就是以前人们普遍认为3-tier优于2-tier的原因。

那么现在这些理论还成立吗? 你可以想想看!

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河