淘客熙熙

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

共:💬7 🌺4
分页树展主题 · 全看首页 上页
/ 1
下页 末页
  • 家园 【原创】SQL 2005 给数据库开发带来的新鲜空气

    点看全图

    外链图片需谨慎,可能会被源头改

    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 帖 引用 (帖内工具实现)
    • 家园 形似而神不似

      表面看起来好像是这样的,Logically 3/multi Tier, Physically 2 Tier。

      用.NET的话,很容易实现零件化,随便几个Tier都行。

      至于Scalability,不是有Server Farm/Cluster吗,这就解决了,而且对程序员来说,还是透明的,做Deployment容易多了。

      这个方案,我个人认为是个大智若愚的方案,佩服得五体投地。

      还是有点不明白,这个OO与Relational DB之间的Mapping不知是如何实现的,很好奇。这好像是业内的一个著名的问题。

      • 家园 OO与Relational DB之间的Mapping微软也只是迈出了第一步。

        我感觉今后的路还长着呢。看看现在的Code,还挺别扭的。

        至于Scalability,Server Farm/Cluster能解决一些问题,但有的问题并不好解决,这要看应用的本质了。所以在很多情况下,那种100多个CPU的大型计算机还是无法取代的,多个小型Server cluster在一起在还是有很多局限的,这也是现在IT界研究的一个重点。

    • 家园 请问3-tier捍卫者的立论依据
      • 家园 大概说来,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的原因。

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

    • 家园 DING!!
分页树展主题 · 全看首页 上页
/ 1
下页 末页


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

Copyright © cchere 西西河