MSSQL网页编程之《SQL Story》摘录五――干系原形

Archive非常适合存储大量的独立的，作为历史记录的数据。因为它们不经常被读取。Archive拥有高效的插入速度，但其对查询的支持相对较差
干系的原形

临时以来，我们习气了称干系型数据库中的表为二维表。由于它有行和列，很简单我们就能够把它统一个二维立体接洽起来，但现实上，这并不是干系型数据库的初志，也并不是切合干系模子的计划。实在久长以来，我对此也只要一个很含混的观点，对立体表的概念虽有嫌疑，却一向无从考证。直到有一天，翻出一本老书――《干系数据库》（石树刚、郑振楣编著，清华年夜学出书社，1993年），这本老书没有甚么盛行的新噱头，却满满铛铛地净是数学实际。这本书读起来并非很诱人，不外切实其实很松散，廓清了我的良多不明的地方。也鼓励我找来各类威望质料重头学起。薄薄一本书，订价只要9.9元，想一想这应该是我在上学时，从旧书摊上买的，大概事先只花了不到五元钱。这一定是我买的性价比最高的一本书了。

在此，我不想从他人书中抄出年夜段原话，拼出一篇笔墨，有这光阴还不如上彀回贴子更有成绩感，我宁肯将我的心得，用其实不周密，但尽量易懂的言语写下。让伴侣们先对干系模子有个基础观点，使浩瀚像我如许非半路出家的读者几懂得一下现实原形，不至于在事情中有所方便。假如你想真正把握干系型数据库的数学模子，请读一读这本不盛行的老书《干系数据库》。固然，另有良多早先的正轨课本也写得很不错，好比如今在我手边的《DATABASESYSTEMCONCEPTS》（机器产业出书社）和《SQL-3参考年夜全》（机器产业出书社）。前两本写得更松散一些，后一本是译得不太好，有些关头中央读着稀里糊涂，不外总得来讲仍是本可贵的好书。

言回正传，如今我们说说干系型数据库究竟是怎样一回事。我们先看一个表：

XYZ

------------------

000

111

001

011

……

这个表存储一个三维空间内的一些点。我们能够很分明地看到，每个完全的行，才代表一个点。仅定位某行某列，它其实不能表达这个表所界说的信息布局。当我们向这个表中拔出或删除数据，它仍代表三维空间内的点集。但假如我们增添一列T（time)呢？那统统全变了，它不再是三维空间了，如今，这个表中存储的是四维的信息了（读过绝对论的伴侣应该懂得，绝对论中的时空就是一个四维坐标系）。删除一列呢？好比Z列，如今我们面临的就是X-Y立体了，这是一个二维坐标系。也就是说，在表中删除或增添或修正多少列，其实不会改动这个表所代表的意义。而修正或增删列，就会改动表的布局，表所代表的意义也就分歧于之前了。表的行和列，并非同等的！我们不克不及复杂地把它了解为一个立体！相反，我以为，将表的布局了解为一个代数空间更符合，如许，表中的每行是这个代数空间中的一个点，那末以后表中的信息就构成了这个空间中的一个点集。固然，这个汇合还可有别的的束缚前提，上面我们从干系模子提及。

在严厉意义上的干系模子中，一个干系形式，包含干系名、无限属性集、属性值域、属性列到值域的映照、完全性束缚和属性间依附。对应数据库中的布局，一般一个干系形式对应一个或多个表和视图。这些表和视图有其各自包含的列，而列有列名、列的数据范例、表和视图的主键束缚、外键束缚、反省、断言、触发器（在SQLServer2000中，已能够在视图中界说索引和触发器，再加上视图自己的SQL剧本，视图以能够界说为一个完全的干系形式）。一个复杂的干系形式能够只由一个表组成，而多个元组（表或视图）构成的干系，其互相的联系关系由外键和触发器来完成。在这个界说中，干系中的各个列（也就是说干系的形式）能够有很强的依附性。好比某些列有主键束缚，另外一些列有援用外键。而行与行之间（也就是说干系之间）的依附只存在于两种情形――外键和触发器。个中外键能够表达为形式上的（也就是列之间的）依附。比方以下定单体系，它由客户表，定单表和

CREATETABLECUSTOMERS(

CUSTOMERIDINTNOTNULL,

FIRSTNAMECHAR(20),

LASTNAMECHAR(20),

CITYVARCHAR(30),

CONSTRAINTPK_CUSTOMERPRIMARYKEY(CUSTOMERID)

)

CREATETABLEGOODS(

IDINTNOTNULL,

NAMECHAR(20)NOTNULL,

NUMBERINT,

PRICEMONEY,

CONSTRAINTPK_GOODPRIMARYKEY(ID))

CREATETABLEORDERS(

ORDERIDINTNOTNULL,

CUSTOMERIDINTNOTNULL,

ORDERDATEDATETIME,

CONSTRAINTPK_ORDERPRIMARYKEY(ORDERID),

CONSTRAINTFK_CUSTOMERFOREIGNKEY(CUSTOMERID)

REFERENCESCUSTOMERS(CUSTOMERID))

CREATETABLEITEMS(

ITEMSIDINTNOTNULL,

ORDERIDINTNOTNULL,

NUMBERINTNOTNULL

CONSTRAINTPK_ITEMPRIMARYKEY(ITEMSID),

CONSTRAINTFK_GOODFOREIGNKEY(ITEMSID)

REFERENCESGOODS(ID),

CONSTRAINTFK_ORDERFOREIGNKEY(ORDERID)

REFERENCESORDERS(ORDERID)

)

以上一表中，一名客户能够有多张定单，定单的定户依附客户表。一张定单能够有多个条目，明细条目又依附于定单和商品的存在。这四个表就组成一个干系形式，四个表都有其主键，表中的别的列依附于主键列。表之间的外键援用则组成了表之间的依附干系。由此连接起了全部形式。每个完全的定单，包含ORDERS表中的订购信息和ITEMS表中的明细，构成一个干系。而一个用户和他的定单，又能够构成一种新的干系，这些干系的形式，能够由SQL语句来表达，这里不具体讲了，伴侣们能够试一下，很复杂的连接查询罢了。我们能够看到，这个典范的干系中，信息的内容之庞大，远远超越了“几个二维立体表”所能界说的。“带有强束缚前提联系关系的多少代数空间点集”大概更好一些。乃至，我们还能够在其上界说更强的束缚，好比用一个触发器包管用户的订购数在某一局限内。当我们增删定单，存货乃至客户时，因为强无力的束缚存在，包管了每一个干系还是完全的。可列的界说自己就是干系形式的一部分，假如我们改动或增删了列，修正的是全部形式。最少一个代数空间，被我们改动了。这也就是行和列的区分。固然，只界说一个表，不给它加以任何束缚，在手艺上是同意的，但如许的表不克不及称为一个干系。它乃至不克不及包管最基础的干系完全性。如之前的文章所示，如许的表容易就能够拔出反复数据，而这些不克不及相互区分的数据其实不能给我们更多的信息。这类没有束缚的表在有用中应该严厉限定于一时表，不该在别的任何场所呈现。

但愿读了这篇文章的伴侣，可以不再犯我现在常初的毛病，创建一个又一个没有任何束缚的表，存进不成靠的数据。我们应该把信息的布局和干系模子间接表达在数据库的计划中，这才是干系型数据库的意义地点。这一次几近没有可实行的代码，大概读者们会成心见。不外至心祝人人能了解我的意义，在干系型数据库的天下中更轻松自若地事情。假如您有品评、表彰、引导，我在这里用心地听取，感谢您的撑持。我在书中专注于SQLServer和InterBase，但愿有Oracle或DB2等别的数据库体系的妙手与我互助，完本钱书的分歧版本内容，与我分享休息的艰苦和乐成的高兴。
因此我们的保存数据方法就是：在删除的动作开始之前，把表数据备份起来，然后留一个空表，在空表上执行“删除”操作。

总感觉自己还是不会SQL

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

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

从项目平台的选择上讲，我们关心的，应该是一款产品能不能满足任务需求，而不是网上怎么说。

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

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

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

一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。）