我们是不是还必定应当利用存储历程(一)

Archive非常适合存储大量的独立的，作为历史记录的数据。因为它们不经常被读取。Archive拥有高效的插入速度，但其对查询的支持相对较差这里我们必需假定，读者都很懂得存储历程，存储历程就是干系型数据库中界说的一个子集。随后，毗连到该数据库的并供应了需要熟悉的用户便可以实行这个存储历程。

我们以为，这里的子程序一词是了解存储历程的知用局限亲睦处的关头，且这里我们所说的存储历程的合用局限亲睦处都是其今朝的形态。我们供认，10年后人们会对存储历程有分歧的意见，且整体来讲加倍偏向于利用。不外,软件范畴中的10年是一段相称长的工夫，相称于太古和古代。

维基百科上关于子程序的界说是一个年夜型程序中的一部分代码，用来实行专门的义务并从某种程序上与别的代码自力。在数据库编程中，子程序则暗示将几个SQL语句组合起来，构成单一的一个庞大语句，即存储历程。如许挪用者便可用一致的接口与数据库交互，易于包管平安，测试，优化和保护，其运转速率也会有所提拔。

上述形貌分析了存储历程的上风和优势。在分歧的高低文中，后面提到的每一个特性都大概成为上风大概优势，这取决于你所创立的使用程序的需乞降束缚，和逻辑的终极庞大性和处置庞大性的体例。一样，开辟体例的分歧也会关于存储历程成为上风或优势发生影响。

客户的说，存储历程并非万恶之源。不外关于那些利用古代概念，形式，工具和手艺完成的带有一样平常庞大性的使用程序来讲，存储历程被以为是一种过期的手艺。我们的概念是存储历程并非相对不克不及利用，而是应当在需要也断定有所匡助时才利用。

在已往的10~15年中，编写体系的趋向是分层并依附于真实的计划形式，不外仍有一个中央被良多人无视。人们仍然常常将营业逻辑放在存储过程当中完成，让两个完整分歧的层的功效混在一同。你会很简单地不当心将某段营业逻辑放在存储过程当中，如许做真的公道吗？今后的几章就枚举一些久长以来一向听到的编写庞大存储历程的来由，个中有些来由在10年前大概加倍公道一些，不外明天事变已产生了良多变更。因而，我们在今后几章中先容一些罕见的有关储历程的传言并举行剖析，固然，个中会依据如今和之前的手艺作出对照剖析。

(本文摘自：Microsoft.NET企业级使用架构计划)提供多语言支持，常见的编码如中文的GB2312、BIG5，日文的Shift_JIS等都可以用作数据表名和数据列名。

换言之，只有在不断的失败中尝试成功，而关于失败的总结却是很少的

至于淘汰的问题，只能说在你的项目周期之内，微软应该都不会倒闭。

相信各位对数据库和怎么样学习数据库都有一些经验和看法，也会有人走了一些弯路总结出自己的经验来，希望大家能把各自的看法和经验拿出来分享，给别人一份帮助，给自己一份快乐

原来公司用过MYSQL自己也只是建个表写个SQL

如果我们从集合论（关系代数）的角度来看，一张数据库的表就是一组数据元的关系，而每个SQL语句会改变一种或数种关系，从而产生出新的数据元的关系（即产生新的表）。

对递归类的树遍历很有帮助。个人感觉这个真是太棒了！阅读清晰，非常有时代感。

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

sqlserver的痛苦之处在于有用文档的匮乏，很多只是表明的工具