主题：【原创】SQL 2005 给数据库开发带来的新鲜空气 -- Highway
SQL2005是微软下一代的数据库系统，以前代号叫做“Yukon”。到现在已经基本就绪了，June Community Technology Preview (CTP)版本已经在大放送了。这个版本和今年11月推出的正式版本应该说是非常的接近了，所以你现在看到的基本就是Final Release的东西了。
那么这个SQL2005有什么特别之处？是不是只是Another Release而已？
我感觉这个SQL2005还是非同一般的，它给数据库开发带来两股新鲜空气，不仅另辟蹊径，很有创新，而且概念非常的大胆，非常具有前瞻性。在这里简单和大家交流一下。希望能抛砖引玉/砖！
一。新的编程模式
现在的应用程序，很少有不和数据库打交道的，不管你是开发桌面应用，还是Web应用；不管你是使用Java还是.NET。在开发过程中，程序员面对的是两个截然不同的世界：一个是面向对象的（Object-Oriented）世界，思考的是Class，Object，Inheritance，Polymorphism。另外一个是关系型世界（Relational world），面对的是Table, join, aggregation，Stored-procedure，Trigger等等。这两个世界需要两种思考模式，这就要求程序员不停的在两个世界之间来回“穿梭”。
能不能将两个世界紧密地结合在一起呢？这个问题很多人在思考。微软在SQL 2005中交出了他们的第一份答卷---〉将.NET引入SQL数据库，让程序员可以在SQL数据库中直接用.NET语言来开发Stored-procedure，Trigger，User-defined function等等。这些程序编译后存放于SQL系统中，用户可以向使用正常的SQL Object一样使用他们。SQL数据库集成了.NET CLR，它将负责执行和管理这些.NET Assembly。
为了让这第一份答卷就给大家一个深刻的印象，微软在Visual Studio 2005和SQL 2005中下了不少功夫，将整个开发环境集成了起来，编程，测试，发布都变得异常的简单。Nice Job!!!并且微软认准了这个方向，不断投入。现在开发研制的下一代C# 3.0以及VB.NET都会将这一特色进一步的突出。
那么，我们现在是不是就可以扔掉T-SQL，全面拥抱.NET了？
你先别这么着急!SQL和.NET的“联姻”这刚刚迈出第一步。他们之间的关系还有待于进一步磨合。事实上，使用.NET在SQL端作开发，T-SQL的思维依然无所不在，这两者之间的Gap还是比较明显的。并且SQL搞了这么多年，在关系型数据的处理上已经炉火纯青了，功能和性能都日臻完美，扔掉T-SQL是绝对不可取的。就现在来看，T-SQL和.NET不是有你没我的竞争关系，而是有你亦有我的互补关系。.NET是对T-SQL的一个补充和加强。
微软有不少专家撰文讨论在开发中T-SQL和.NET的相互关系，具体到什么情况下用T-SQL最有效，什么情况下使用.NET更合理。有兴趣的朋友可以上微软的网站去看看这些技术文章。简单来说，可以归纳为两点：
1. 对于计算密集型以及运算逻辑复杂型操作，CLR-based .NET程序更合适
2. 对于传统意义上的数据存取修改，T-SQL效率更好，性能更好
二。新的数据存取模式
DAO,ADO,ADO.NET,ODBC,OLE-DB,JDBC,ODBC-JDBC Bridge，BDE，Jet Engine...开发过数据库的朋友们一定对这些名词不会陌生。我们选择一种程序语言，一种操作系统以及一种数据库系统，我们就要选择一种存取数据的方式。用术语说就是要选择“数据库驱动程序”。有时候这些驱动程序很简单（比如Java Type 4 JDBC），但有的时候可能会非常复杂和Messy。比如我曾经有过恐怖的Oracle Client Driver经历。
难道不能有一种技术把这些“讨厌”的技术细节都Wrapper起来，提供给程序员一个统一的，简单的接口吗？不管你是在那个平台上，使用什么程序语言，接触什么样的数据库系统？
Web Service可能就是这样一个“救世主”。它横空出世，使用业界标准的HTTP/HTTPS，SOAP/XML，WSDL以及UDDI。大家都认可，大家都支持。Web Service将人们梦想梦想已久的“跨平台互操作”变为现实。
SQL 2005充分考虑到了Web Service这一特点，将它紧密地集成了进来。其结果是SQL 2005的东西可以直接通过Web Service发布出去。通过Windows 2003 Server的HTTP.SYS构架，SQL 2005可以甩掉IIS Web server，直接和Kernel的HTTP.SYS连接起来，收听Web service请求并给与答复。这样，SQL 2005就甩掉了所有的“中间人”，直接可以用HTTP向外界提供服务了。这一变化有两点巨大的影响：
1. 任何人，任何语言可以从任何平台上向SQL 2005提出数据请求。只要有正确的安全和认证信息，SQL将以SOAP标准给与答复。
2. 经典的3-tier程序模式突然间简化为/倒退为2-tier了。客户端和数据库端没有middle-tier了。人们一下子炸锅了--“怎么可以这样？”
SQL的设计师Jim Gray(微软巨牛之一，人称SQL God)笃信简洁就是美。它认为只要技术上没有问题，2-tier当然比3-tier好。当他和.NET的设计师Don Box说起此事的时候，老Don“破口大骂” -- “You damn idiot...”。在老Don眼里，3-tier程序模式是不容动摇的，是天经地义的！
事实上，使用Web Service作为数据存取手段很多的人也不赞同。也有许多讨论在热烈的进行当中......
一种技术从概念开始，然后发育培植成为了产品，再经过推广和应用成为人们解决问题的手段。这中间要经过多次反复，多次的修正。真正有价值，有潜力的技术才会最终存活下来。微软SQL 2005中的这两点新的“概念”是否能被业界接受，在实践中到底效果如何现在下结论还为时过早，但这种敢于创新的精神还是令人赞许的。
让我们拭目以待吧！
本帖一共被 1 帖 引用 (帖内工具实现)
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的原因。
那么现在这些理论还成立吗？ 你可以想想看！
许多J2EE应用，何止3个tier?
但对一些real time application, 还是tier越少越好。我倾向于简单就是美。
表面看起来好像是这样的，Logically 3/multi Tier, Physically 2 Tier。
用.NET的话，很容易实现零件化，随便几个Tier都行。
至于Scalability，不是有Server Farm/Cluster吗，这就解决了，而且对程序员来说，还是透明的，做Deployment容易多了。
这个方案，我个人认为是个大智若愚的方案，佩服得五体投地。
还是有点不明白，这个OO与Relational DB之间的Mapping不知是如何实现的，很好奇。这好像是业内的一个著名的问题。
我感觉今后的路还长着呢。看看现在的Code，还挺别扭的。
至于Scalability，Server Farm/Cluster能解决一些问题，但有的问题并不好解决，这要看应用的本质了。所以在很多情况下，那种100多个CPU的大型计算机还是无法取代的，多个小型Server cluster在一起在还是有很多局限的，这也是现在IT界研究的一个重点。