41071.htm

来自「一本很基础的SQL讲解」· HTM 代码 · 共 322 行 · 第 1/5 页

<P>用户界面为浏览和设置SQL Server 2005实例层权限提供了一个简单的方法。SQL Server 2005实例层特性也可以被以下命令控制： </P>
<P>◆Transact-SQL sp_con图 命令<BR>◆使用服务器管理对象(SMO)服务器对象配置类管理代码</P>
<P><STRONG>用Transact-SQL激活API</STRONG></P>
<P>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
<TBODY>
<TR>
<TD class=code bgColor=#e6e6e6><PRE><P>-- Enable &amp; Check the Database Engine .NET Framework 编程 api <BR>sp_configure N'clr enabled', 1<BR>go<BR>reconfigure <BR>go<BR>SELECT sc.* <BR>FROM sys.configurations AS sc<BR>WHERE sc.[name] = N'clr enabled'</P></PRE></TD></TR></TBODY></TABLE></P>
<P><STRONG>为工作选择正确的工具</STRONG></P>
<P>工具和API的选择取决于其他因素例如你内部员工的技术水平，depend on many other factors such as the skills of your internal staff, the recommendations of the 第三方软件厂商为你公司运行系统的推荐，系统的需求等等。</P>
<P><A href="/files/uploadimg/20070227/1816172.jpg" target=_blank><IMG height=285 alt="" src="/files/uploadimg/20070227/1816172.jpg" width=450 border=0></A>&nbsp;</P>
<P><STRONG>图 3</STRONG></P>
<P>以上插图显示出了每一个数据库管理员都将面对的进退两难的选择。 有些选择是很简单的但是有些选择是非常复杂的,特别是当有很多方法都可以实现这些功能时，而且在技术选项之间也没有绝对的说明。</P>
<P>在这些情况下，原型就显得愈加重要。一个快捷的执行方法使用两种或两种以上的选项，这样可以使选择更加清楚。</P>
<P>根据以前的经验, 经验丰富的数据库管理员是保守的。同样的, 新技术不可能很轻松的就实行起来；他们必须首先被理解然后在他们完整引进至生产环境前需要进行严格的测试。另外，冒着动摇数据库的危险而导致用户对数据库管理的系统完整性不信任，可能会威胁到数据库管理员工作的安全。一个长远的假设是开发者会更加期望捕获风险和采用新工具来提高他们的生产力，以及扩大他们的知识面宽度，以帮助他们可以为用户提供的更多的解决方法。数据库引擎.NET Framework 编程模型具有强大功能是毫无疑问的，很多数开发者将会感激这项在数据库中以第一类编程语言写代码的新功能。</P>
<P>因此，在保持系统的稳定性和获得更大的生产力着两者之间就出现了矛盾。那么如何处理这个矛盾哪？ </P>
<P>答案就是找到平衡，理解时机，然后更加着重于理性的定义选择，基于严格的标准做技术选择。这个章节给出了一些指导方针，送而找到一个折中的平衡点。</P>
<P>#p#</P>
<P>第一组观点就是在可能出现错误的地方使用新功能提供指导：</P>
<P><STRONG>◆深度相关的数据访问</STRONG><BR>不要将简单的查询执行移出Transact-SQL。Transact-SQL 基本设置访问将会比在.NET Framework中移进移出数据更快速，特别是基本设置查询被类指针所代替。排错包含了此种潜在信息可能的花费。应该注意那些相反的请求，那些被查询所替代的复杂的计算，在这种情况下，将逻辑移动到.NET Framework程序里，在那里计算将被完全编译，逻辑可以明显改善。</P>
<P>那些简单的计算和基本的关系型数据访问在Transact-SQL和.NET Framework执行环境之间转换所需的花费是很明显的。在这样的情况下，Transact-SQL很可能将会胜过CLR。 </P>
<P><STRONG>◆长时间与转,外部呼叫</STRONG><BR>While it is tempting to use the new functionalityt档使用新功能的同时可以更进一步的与现有的商业系统结合是很具诱惑力的,花费时间来确保最终用户在呼叫外部API和外部系统时的花费不会得到消极的影响是非常重要的。这些影响可能在用户定义功能里特别的明显，他们可能会导致对表的每一行查询。在应用于一个10,000-row表时，外部呼叫可能在在线系统中从每秒一行的状态突然变成不可用的。 </P>
<P><STRONG>◆不必要使用用户定义类型</STRONG><BR>当对象数据可能被简单的映射成一个一队夺得关联数据类型，你可以中止或继续相关。用户定义类型有以下几种：</P>
<P>◆8-K大小约束。他们必须适合单一SQL Server数据页。 <BR>◆如果进行更新时，在UDT中的所有数据是可读和可重写的。<BR>，当连接大队列对象时，应该担心同样的大小约束会被应用于用户定义聚合。</P>
<P><STRONG>◆用户定义聚合以及在线支持</STRONG><BR>用户定义聚合不可以与SQL Server 索引师徒俩和使用，因为为在线报表操作来自动整合数据是不可能的。 如果状态数据是可接受的，然后，由定期的缓存聚合所产生的结果是一个分离的可创建和可维护的表，它可以被一个索引视图替代。</P>
<P><STRONG>◆与早期SQL Server版本兼容<BR></STRONG>如果你的应用程序必须支持早期的SQL Server版本，你不可以使用此功能。</P>
<P><STRONG>◆适当的使用技术</STRONG><BR>数据库引擎 .NET Framework 编程 API 为数据库程序员引入了很多新可能性。然而, 你可能会避免草率的使用这个新功能除非你可以清楚地了解它使用的基本原理。</P>
<P>这些观点可能看起来像是为不发展技术提供了一个很有利的实例。然而, 这有很多强有力的例证可以证明很多值得思考的优点。他们包括以下这些：</P>
<P><STRONG>◆.NET Framework和the Visual Studio编程环境的杠杆作用</STRONG> <BR>这是获得大多数利润的关键所在，它们以开发者的生产力和新兴事物形式被获取。</P>
<P>在SQL Server 2005和 Microsoft&reg; Visual Studio&reg;2005这代中, 整合开发环境和.NET Frameworks是他们第二代的第三版， 它允许了一个重要的开发者回馈。也就是说使用者接口能够快速应用开发，而且类库提供了一整套大量的对象和方法使得开发者可以不用花费力气来编写大量的普通任务。</P>
<P>.NET Framework (C#, Managed C++, and Visual Basic.NET)的第一类编程语言提供给程序员更多的对错误处理的控制也为访问堆栈和其他调试信息提供了更好的诊断。</P>
<P>在不需要提升权限的情况下程序员有权使用大多数本地功能，也就说例如大量的XML, 数组，常规表达式，数据功能操作等等都是可被访问的且不会威胁数据的安全。</P>
<P>另外, 因为这些代码是编译然完成的，他们已经被转换成机器语言，所以在执行业务逻辑的时候会比Transact-SQL更快。</P>
<P>举例可能会在以下几种情况下出现：</P>
<P>在表格样式里连接远程网站服务来访问数据 (在数据层里为web服务整合更加清晰的权限)</P>
<P>◆基于数据库中的改变，调用第三方厂商控制，来添加一个ERP系统。<BR>◆为了你的商业用途调用代码库中提供的数据类型和函数。例如你的研究，商业，销售的需求。<BR>◆替代扩展存储过程 (XPs)<BR>在数据库引擎 .NET Framework 设计 API到来之前, 提供外部世界使用权的唯一方法是通过扩展存储过程和sp_OA* 存储过程。 然而, 早期文件证明，即使由经验丰富的开发者使用，这种方法具有仍对数据库稳定性极具威胁性。</P>
<P>推荐那些拥有提供外部商业逻辑的扩展存储过程系统或者那些通过sp_OA*存储过程使用对象模型操作的数据库管理员考虑赶快采用这种新技术，因为 SQL CLR 更加安全。</P>
<P>使用SQL CLR有以下优势： </P>
<P>◆不会因为用户代码的错误导致SQL Server服务发生故障的情况。<BR>◆没有发生管理用户代码内存漏洞导致SQL Server减速或暂停的可能性。<BR>◆通过SQL Server’s内存管理器控制系统资源更具操作性和可测量性。<BR>◆不会出现安全故障，因为它完全整合了SQL Server和 .NET Framework 环境的安全。</P>
<P>这个优势可能不会在不安全情况下的程序集注册中应用， 因为他们可以调用不可控的代码或者线程库（例如对话产生代码，线程创建代码或者干涉进程关联处理的代码。）或者因为他们使用COM自动操作。此外，通过引起违法访问或者内存漏洞，他们可能仍然对SQL Server 实例有影响。</P>
<P>大多数扩展存储过程可以被替代，特别是考虑到 C++ 是一个可利用的代码编写工具。</P>
<P>◆<STRONG>数据更新确认</STRONG><BR>为多用户共同改变数据强制指定一个商业规则是许多系统一直面临的一个问题。新的API允许这些逻辑在数据库队列中移动触发器来确保所有更新是一致的。</P>
<P>一个例子可能会要求以特别的顺序引入数据，而其中的一些系统和技术是通常是不能直接被Transact-SQL触发器访问的。触发器可以检测出一个新的用户是不是第一次进入，是不是一个来自远程的可信任的IBM大型机系统。他可以为所有的商业用户提供风险管理。</P>
<P>#p#</P>
<P>◆<STRONG>减少网络通信量</STRONG><BR>一些运算法则要求所有或者大比率的数据产生结果。然而，在服务期间移动大量数据是非常消耗CPU资源的。因此，好的算法可以降低数据对CPU的消耗和对网络的消耗。也可以使应用程序有更好的性能。</P>
<P>例如这可能影响以下的内容：<BR>&nbsp;<BR>◆统计计算需要所有数据以产生输出结果。<BR>◆在SQL的数据集要连接到一些非关系型数据库时，连接服务不可用及SQL上的数据比远程服务器上的数据更大时。</P>
<P>◆<STRONG>写入常规目的函数</STRONG></P>
<P>一个整合意图功能具有记下几个特征：</P>
<P>◆数据以论据行为传递。<BR>◆针对内部函数存在很少或者没有额外的数据访问。<BR>◆复杂的计算通过是一个循环中的数据的类指针代码被应用的，它是每次处理一行。</P>
<P>在CLR执行环境下编译开销与环境之间转换所花费的消耗相比更具有优势，在性能测试中，SQL团队测试出大约每个调用三个整形操作的降低。</P>
<P>实例中包括了模拟每日的事务处理量，以及一些不长用的数据模拟。</P>
<P>◆<STRONG>标量工具, 用户定义类型</STRONG><BR>虽然大多数数据可以被映射为关系模型，这里仍然有很多例子表现出用户自定义数据类型需要值得考虑的地方：<BR>◆此类型约束的外部行为是为了使它被SQL Server所接受。一个实例就可以是一个表现了UTC 功能的日期类型。<BR>◆此类型使用了封装来保护它的内容及数据经常被一起读和更新的位置。一个实例也可以是一个的空间的数据类型或者一个复合数字的执行。</P>
<P>◆<STRONG>使用自定义和用户定义聚合的功能</STRONG><BR>许多的行业数据在本地聚合操作中是基于all/subsets分组定制输入的，例如SUM, AVG, 和MIN, 以及其它公司。实例可能进行一个傅立叶变换或者进行一个精确的预先计算的处理。用户自定义聚合允许通过多线程的散开/散入(关联执行) 操作，因而，通过多重处理器应该很好的被分离。</P>
<P>◆<STRONG>高性能表值，用户定义函数</STRONG><BR>在保存实例化之前从流动表值，用户定义函数中通过支持局部结果的时候，许多运算法则不要求从外部数据源而来的涵盖所有条目的完整列表。一些例子包括了 “获得最新的股票价格”, “获得最新的事件日志”, 和 “获得队列中第一个项目”。用户定义函数支持流动的数据。数据是被查询到的而不是在某一时间点获得的，因此应该避免读取大量结果并且插入到内存中。</P>
<P>它的实际能力超过Transact-SQL表值,用户定义函数, 而Transact-SQL在它被调用时必须展示实例化所有数据。在这种情况下， 普通的部分请求查询它绝对胜过传统的用户定义函数。 </P>
<P>我们应该从一个开发和系统管理服务共同体的角度来理解这个罗列出好坏用途的列表</P>
<P><STRONG>程序范例</STRONG></P>
<P>开发者用Visual Studio编写代码。 这是用数据库引擎 .NET Framework 设计API来编写程序最适合的工具。使用其它工具来开发程序是有可能的，例如Express toolset甚至Windows 记事本,但是他们缺乏数据库引擎的神奇功能， 整合了MSDN和Visual Source Safe, 以及其它团队发展工具。另外，Visual Studio提供了一个具有多样性的配置，测试，贺调试工具，通过它经验丰富的开发者可以开发高终端程序。</P>
<P><A href="/files/uploadimg/20070227/1816173.jpg" target=_blank><IMG height=325 alt="" src="/files/uploadimg/20070227/1816173.jpg" width=450 border=0></A>&nbsp;</P>
<P><STRONG>图 4</STRONG></P>
<P>举一个简单的例子: 在开发者完成他们的解决方案之后，他们使用.NET Framework编译器来编译程序集(一个后缀为.dll 的文件存储在目标文件服务器上)然后不是手动就是自动的再数据库中配置二进制程序集。</P>
<P>在程序集assembly被加载进数据库后，它就与原始的文件（以.dll为后缀的文件）独立开来。 这意味着不用担心外部对象依赖关系就可以对数据库进行备份，移动甚至存储操作。因为他们全部预先加载进数据库中。 </P>
<P>注意原始源代码必须仍然维护操作，而且所有改变都应该被记录下来。</P>
<P>以下的建议是为了使开发者得到最大生产力：</P>
<P>◆开发者应该拥有一整套的专业工具<BR>◆Visual Studio 2005 组系统和 MSDN<BR>◆临时数据库引擎的SQL Server 2005 Express 。.NET Framework API users和一些测试和开发的限制窗体<BR>◆为正规的数据库 .NET Framework API 用户提供的SQL Server 2005 开发者版本 <BR>◆为组访问源代码和释放管理提供的Visual 源安全或者一个同等的源控制管理系统<BR>◆开发者需要访问类产品数据。<BR>◆一个拥有合理的相关表大小继承和模糊的灵敏型客户数据的scaled-down版本的数据库产品, 应该允许被访问使它能够被测试和更正原形。一个很重要的解释是其它的工具，例如SQL Server 2005整合服务，可以被用来为你的产品数据库创建一个丰富的开发者版本，你的产品数据库可以包含隐式信任卡，名称，地址，及社交安全数字。<BR>◆访问测试web服务来测试和其他系统的整合。</P>