MSSQL网站制作之关于 OLE DB 和 .NET 的思索

因此我们看到，这些信息足够让我们对单个操作实现“逆操作”。关于OLEDB和.NET的思索

你我其实不了解。不外，面临一个实其实在的成绩“软件究竟是甚么？”，我却没有符合的谜底。

假想一下如许一个场景：在一个旅游怀念品商铺，你正专注于购置一些没用的器材（次要是怀念品），以便让到机场接你的伴侣和亲戚感应高兴。这时候，常常会有人问你：“第一次来吗？出差仍是度假？”

以是，假如你是在做和软件有关的事，而不是在度假，那你就不能不面临这个实际的成绩。

那末，软件究竟是甚么？

回覆这类关于存在的成绩是很坚苦的，特别是假如此时你正在闲逛，背着一背包明信片、考拉图片和袋鼠玩具，包上还印着防鳄鱼的黄色告诫标记。

我勉力使本人的头脑自在而又只管复杂。起首，软件是跟盘算机相干的。软件也和演化有关。固然，软件还与数据（出格是数据存储和操纵）有关。

回到旅店后，我仍在思索上面的成绩――关于数据的存储和利用，我最近几年来察看到了如何的演化？因而，我入手下手思索OLEDB及其在.NET方面的演化。
软件退化论
从汗青角度来讲，ODBC举行了第一次严厉实验：它试图创立一种一致的使用程序会见数据库的路子。像软件中的其他器材一样，ODBC的计划目标是满意某种特定的必要。在信息手艺永无尽头的退化历程中，它创始了一个新阶段。

ODBC必需供应一个公用的（最好是笼统的）API，用来会见数据库，而不必思索数据库的外部细节、言语和表的构造。可是，跟着工夫的推移，人们发明，面临新的数据驱动使用程序的计划与机关办法，ODBC愈来愈没法乐成地满意必要。

软件也有本人的退化论。ODBC以分歧的称号、分歧的编程模子和新的功效顺应了变更，保存了上去，同时又坚持了它的真正任务。ODBC持续以OLEDB的称号和功效供应（或多或少地）开放式数据库毗连的功效。

OLEDB作为一种编程接口，将Microsoft通用数据会见(UDA)战略的实际观点使用于理论。UDA可以经由过程基于COM的单一编程接口来会见各类范例的数据，包含干系型、非干系型和条理布局型数据。

OLEDB是作为一种组件手艺而计划的，其特性是接纳了多层模子。在COM桥的一侧是用于保存数据的服务器组件，另外一侧则是懂得怎样毗连和哀求数据的客户端组件。前者称作OLEDB数据供应者；尔后者则称作OLEDB利用者。

利用者和供应者都是COM工具，并可以经由过程一套COM接口相互通讯。这类基于COM的通讯可被归纳综合为在笼统工具（如DataSource、Session、Command和Rowset）上实行的操纵。因而，当利用者毗连到DataSource，翻开Session，收回Command，并前往数据Rowset时，便会呈现这类情形。

ODBC的这一退化使UDA和OLEDB增加了一种功效，这类功效就像一个复杂的干系表一样，将一切的企业数据粘合在一同，不管它们是干系型、非干系型仍是条理布局型。
OLEDB模子
说到数据会见，我们有两种基础选择。一种是像UDA同意的那样，接纳通用数据会见战略。另外一种则偏向于利用通用数据布局。它强即将现有的一切信息从以后的数据存储区挪动到一个能包涵一切数据范例的数据库服务器。

利用OLEDB，必要将客户一切的信息粘合在一同。另外一种体例是，强即将客户端晋级至新的、更壮大的、独一的DBMS，而这个DBMS可以处置任何格局的信息。

与ODBC比拟，OLEDB对数据物理布局的依附更少。别的，它不用严厉基于SQL。OLEDB命令能够是SQL语句，也能够是其他的一些器材。总的说来，能够将它们看做以任何可以为方针供应者了解的语法写成的文本字符串。

像ODBC一样,OLEDB接纳C++的观点举行计划，以尽量进步两头层模块数据会见的功能。基于一样的缘故原由，OLEDB不克不及间接在VisualBasic

XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应该是相当的熟了！）

对于微软系列的东西除了一遍遍尝试还真没有太好的办法

Mirror可以算是SQLServer的Dataguard了。但是能不能被大伙用起来就不知道了。

其实可以做一下类比，Oracle等数据库产品老早就支持了java编程，而且提供了java池参数作为用户配置接口。但是现在有哪些系统大批使用了java存储过程？！连Oracle自己的应用都不用为什么？！

groupby子句可以将查询结果分组，并返回行的汇总信息Oracle按照groupby子句中指定的表达式的值分组查询结果。

我个人认为就是孜孜不懈的学习

然后最好有实践机会，能够把实践到的和实践结合起来，其实理论思考是个非常困扰和痛苦的事情

理解了存储结构，再阅读下性能优化的章节基本上会对sqlserver有个清晰地认识