SQL Server 2008数据库设计与实现(关系数据库实现的通关宝典)--随书源代码

CruiseYoung提供的带有详细书签的电子书籍目录 http://blog.csdn.net/fksec/article/details/7888251 该资料是《SQL Server 2008数据库设计与实现》的随书源代码 对应的书籍资料见: SQL Server 2008数据库设计与实现(关系数据库实现的通关宝典) 基本信息 原书名： Pro SQL Server 2008 Relational Database Design and Implementation 原出版社： Apress 作者： (美)Louis Davidson    Kevin Kline    译者： 程桦 张绪业 丛书名： 图灵程序设计丛书 数据库 出版社：人民邮电出版社 ISBN：9787115215543 上架时间：2009-10-30 出版日期：2009 年11月 开本：16开 页码：560 版次：1-1 编辑推荐 　　 资深数据库专家的心血力作 　　 SQL Server设计思想的独到解析 　　 关系数据库实现的通关宝典 内容简介 　　本书深入浅出地介绍了目前世界上最受欢迎的数据库管理系统之一——sql server。全书共分三个部分：第一部分阐释了数据库的基本概念，讲解了数据库建模语言；第二部分展示了从概念建模到在 sql server 2008上真正实现数据库的过程；第三部分深入探讨了 sql server若干方面的技术细节，如数据保护、索引、并发访问等。通过将理论融入数据库实践，清晰地讲解了关系型数据库的设计原则，完整地展示了如何进行良好的关系型数据库设计，深入揭示了 sql server 2008的技术细节。. 　　本书浓缩了作者作为 sql server数据库架构师多年来丰富的实践经验，适合各类数据库开发和管理人员学习参考。... 作译者 作者: 　　Kevin Kline是Quest软件公司SQL Server解决方案的技术战略经理。Kevin从2004年开始就是微软的SQL Server MVP，他是国际SQLServer专家联盟(PASS)创辽委员会的成员和下一届总裁。他独自写作或参与合著了好几本书，包括SQL in a Nutshell(O'Reilly，2004)、Pro SQL Server 2005 Database Design and Optimization(Apress，2006)以及Database Benchmarking：Practical Methods for Oracle&SQL; Server(Rampant，2007)。Kevin给SQL Server Magazine和Database Trendv and Applications杂志供稿，他的博客可以在SQLBlog．com和SQLMag．com上找到。在世界范围内的会议上，比如微软的Tech Ed、PASS社区峰会、微软汀论坛、DevTeach以及SQLConnections，Kevin也是人气最高的演讲者。从1986年开始Kevin就活跃在IT工业中。.. 　　Kurt Windisch是Levi，Ray，and Shoup，Inc．公司内部IT部门的应用程序监管，该公司是——家技术方案的全球供应商，总部位于伊利诺伊州的Springfield。Kurt在IT工业中的经验超过了17年。他在SQL Server专家联盟的董事会中服务了5年，为很多SQL Server杂志供过稿，也在讨论SQL Server数据库编程的国际会议上发过言。 　　Louis Davidson，作为企业数据库开发人员和架构师，他拥有超过15年的工作经验。目前他是田纳西州Nashville的Christian广播网络和NorthStar工作室的数据架构师。对于Louis而言，他全部的职业经验几乎都与微软的SQL Server有关，从早期版本一直到当前最新版本的Beta版。Louis是一本讲数据库设计的书的4个版本的主要作者。Louis主要的兴趣领域是数据库架构和用T-SQL编码，并且，他设计过许多数据库，在这许多年中编写过数以千计的存储过程和触发器。 　　Scott Klein是一位独立咨询师，对SQL Server、．NET和XML相关的所有知识都充满热情。他是几本书的作者，这包括Professional SQL Server 2005 XML(Wrox，2006)和Professional LINQ(Wrox，2008)，他还为SQL PASS Community Connector写每两周一次的特辑文章。他也为好几个网站供稿，这包括Wrox(http：／／www．wrox．com)和TopXML(http：／／www．topxml．com)。他经常同佛罗里达附近的SQL Server和．NET用户群体交流。Scott住在佛罗里达的Wellington，当他不坐在计算机前时，你会发现他和自己的家人在一起，或者骑着他的雅马哈摩托车轰鸣在当地的摩托车越野赛赛道上。你可以通过ScottKlein@SqlXml．com联系他。 目录 封面 -17 封底 -16 扉页 -15 版权 -14 译者序 -13 关于作者 -12 序 -11 前言 -10 致谢 -6 目录 -4 第1章 数据库概念简介 1 1.1 数据库设计阶段 2 1.1.1 概念阶段 3 1.1.2 逻辑阶段 5 1.1.3 实现阶段 5 1.1.4 物理阶段 6 1.2 关系数据结构 6 1.2.1 数据库和模式 6 1.2.2 表、行和列 7 1.2.3 信息原则 10 1.2.4 域 12 1.2.5 元数据 13 1.2.6 键 13 1.2.7 未显式赋值的项（NULL） 18 1.3 实体之间的关系 20 1.3.1 二元关系 21 1.3.2 非二元关系 24 1.4 数据访问语言（SQL） 24 1.5 理解依赖性 25 1.5.1 函数依赖性 26 1.5.2 判定 26 1.6 总结 27 第2章 数据建模语言 28 2.1 数据建模介绍 28 2.2 实体 29 2.3 属性 32 2.3.1 主键 33 2.3.2 替代键 35 2.3.3 外键 35 2.3.4 域 36 2.3.5 命名 38 2.4 关系 39 2.4.1 识别性关系 40 2.4.2 非识别性关系 40 2.4.3 角色名字 43 2.4.4 关系基数 44 2.4.5 动词短语（关系名字） 49 2.5 描述信息 51 2.6 其他建模方法 52 2.6.1 信息工程 53 2.6.2 Chen ERD 54 2.6.3 Visio 55 2.6.4 Management Studio数据库关系图 56 2.7 最佳实践 57 2.8 总结 57 第3章 概念阶段数据建模 59 3.1 理解需求 60 3.2 文档化过程 61 3.3 需求收集 62 3.3.1 客户访谈 63 3.3.2 要回答的问题 64 3.3.3 现存的系统和原型 67 3.3.4 其他类型的文档 67 3.4 识别对象和过程 69 3.4.1 识别实体 70 3.4.2 实体间关系 76 3.4.3 识别属性和域 82 3.5 识别业务规则和业务过程 90 3.5.1 识别业务规则 90 3.5.2 识别基础业务过程 92 3.6 完成概念模型 93 3.6.1 识别明显的、额外的数据需求 94 3.6.2 和客户一起评审 95 3.6.3 重复以上步骤直到客户同意你的模型 95 3.7 最佳实践 95 3.8 总结 96 第4章 规范化过程 97 4.1 为什么要规范化 98 4.1.1 消灭重复数据 98 4.1.2 避免编写不必要的代码 98 4.1.3 给表瘦身 98 4.1.4 最大化聚集索引的使用 99 4.1.5 降低每张表中索引的数量 99 4.2 规范化应该走多远 99 4.3 规范化过程 100 4.4 实体和属性的形式：第一范式 100 4.4.1 所有属性必须是原子的 101 4.4.2 实体的所有实例必须包含相同数量的值 104 4.4.3 实体中出现的所有实体类型都必须不同 106 4.4.4 第一范式所避免的不规则编程 106 4.4.5 当前设计不符合第一范式的线索 110 4.5 属性间的关系 111 4.5.1 第二范式 111 4.5.2 第三范式 116 4.5.3 Boyce-Codd范式 121 4.6 实体中的多值依赖 124 4.6.1 第四范式 124 4.6.2 第五范式 135 4.7 非规范化 136 4.8 最佳实践 136 4.9 总结 137 4.10 额外的例子 137 4.11 本书迄今为止所讲述的故事 142 第5章 实现基础的表结构 144 5.1 评审逻辑设计 147 5.2 变换设计 148 5.2.1 选择名字 148 5.2.2 处理子类型 151 5.2.3 决定树的实现方式 155 5.2.4 选择键的实现方式 156 5.2.5 决定域的实现方式 161 5.2.6 设置模式 172 5.2.7 评审“最终的”实现模型 172 5.3 实现设计 173 5.3.1 创建基本表结构 175 5.3.2 添加唯一性约束 183 5.3.3 构建默认约束 189 5.3.4 添加关系（外键） 195 5.3.5 处理排序规则和排序 205 5.3.6 计算列 209 5.3.7 实现用户定义的数据类型 212 5.3.8 文档化你的数据库 220 5.3.9 处理依赖信息 222 5.4 最佳实践 225 5.5 总结 226 第6章 保护数据的完整性 228 6.1 最佳实践 229 6.2 自动数据保护 231 6.2.1 声明性数据保护 231 6.2.2 基本语法 233 6.2.3 基于简单表达式的CHECK约束 235 6.2.4 基于函数的CHECK约束 237 6.2.5 约束引起的错误 242 6.2.6 DML触发器 244 6.2.7 处理来自触发器和约束的错误 277 6.3 手动数据保护 280 6.4 更多最佳实践 287 6.5 总结 287 第7章 模式与查询技术 289 7.1 预计算值 290 7.1.1 序列表 290 7.1.2 日期计算 297 7.2 二进制大型对象（BLOB） 305 7.3 存储用户自定义数据 307 7.3.1 一长串通用列 308 7.3.2 实体－属性－值（EAV） 309 7.3.3 往表中增加列 313 7.4 通用实现对象 318 7.5 反模式 319 7.5.1 多用途键域 320 7.5.2 通用键引用 322 7.5.3 对非结构化数据的过度使用 325 7.6 总结 326 7.7 回顾与展望 326 第8章 数据访问安全 328 8.1 安全主体与安全对象 329 8.2 数据库安全概述 330 8.2.1 模拟 331 8.2.2 权限 333 8.2.3 控制对象访问 334 8.2.4 角色 338 8.2.5 模式 344 8.3 通过T-SQL编程对象控制对象访问 345 8.3.1 存储过程和标量函数 346 8.3.2 对象内模拟 347 8.3.3 跨数据库边界 352 8.3.4 不同的服务器（分布式查询） 357 8.4 视图与表值函数 357 8.4.1 一般用法 358 8.4.2 使用视图实现可配置的行级安全 360 8.5 数据混淆 364 8.6 监视与审核 367 8.6.1 服务器与数据库审核 367 8.6.2 使用DML触发器查看表的变更历史 371 8.6.3 DDL触发器 374 8.6.4 分析器日志 377 8.7 最佳实践 379 8.8 总结 380 第9章 表结构与索引 382 9.1 数据库物理结构 383 9.1.1 文件与文件组 383 9.1.2 分区与页 386 9.1.3 页中的数据 388 9.1.4 分区 391 9.2 索引概览 393 9.3 基本索引结构 393 9.4 索引类型 395 9.4.1 聚集索引 395 9.4.2 非聚集索引 397 9.4.3 聚集表上的非聚集索引 398 9.5 索引创建的基本方法 400 9.6 基本的索引使用模式 402 9.6.1 使用聚集索引 403 9.6.2 使用非聚集索引 405 9.6.3 使用唯一索引 416 9.7 高级的索引使用案例 416 9.7.1 外键索引 416 9.7.2 索引视图 419 9.8 最佳实践 422 9.9 总结 423 第10章 并发编程 425 10.1 什么是并发 426 10.2 查询优化的基础知识 427 10.3 操作系统与硬件因素 428 10.4 事务 429 10.4.1 事务语法 430 10.4.2 已编译的SQL Server代码 437 10.5 SQL Server并发控制 444 10.5.1 锁 445 10.5.2 隔离级别 448 10.6 完整性与并发性编程 459 10.6.1 悲观锁定 459 10.6.2 实现单线程代码块 461 10.6.3 乐观锁定 463 10.6.4 基于行的锁定 464 10.6.5 逻辑工作单元 469 10.7 最佳实践 470 10.8 总结 471 第11章 数据访问策略 472 11.1 即席SQL 473 11.1.1 优点 474 11.1.2 缺陷 480 11.2 存储过程 484 11.2.1 封装性 485 11.2.2 动态存储过程 486 11.2.3 安全性 488 11.2.4 性能 490 11.2.5 缺陷 491 11.2.6 观点 495 11.3 T-SQL与CLR（公共语言运行时） 497 11.3.1 选择T-SQL的准则 500 11.3.2 选择.NET的准则 501 11.3.3 CLR对象类型 501 11.4 最佳实践 503 11.5 总结 504 附录A Codd的RDBMS十二法则 506 附录B 标量数据类型参考 511 索引 538 译者序 　　如果将数据库称为现代数字生活的基础，那么这样的说法一点也不夸张——大型企业应用、网站，所有这些东西的背后，都是数据库在支撑。并且，最终说来，产生价值的并不是绚丽的界面和现代化的输入方式，而是存放在数据库中的数据。不幸的是，虽然关系型数据库历经了约30年的发展，有成熟的理论和大量的实践基础，但是，大多数设计、开发人员在设计数据库结构时仍然是“跟着感觉走”，根据业务的需要和编程的方便，把字段这张表放几个那张表放几个完事。对这样设计出来的数据库，只需多问几个为什么——业务模型是如何体现的？数据完整性如何保证？性能是如何权衡的？——恐怕设计者就该崩溃了。. 　　这也难怪，设计、开发人员在学校中学习数据库时，理论书籍离实际开发较远——试问有几个人能够以可实践的方式把规范化的几条原则阐述清楚？在工作时，使用的数据库资料和书籍又往往是“手册型”，大多仅仅讲解特定数据库提供的功能。 　　正如作者所说——“我的书目标很简单，那就是填补这个空白，架起学院教科书与通常针对SQL Server所写的，纯粹面向实践的书之间的桥梁”。翻译的过程中，译者感到此言不虚：作者从数据库的基本概念到数据库建模，从如何运用规范化原则到如何做成实际的数据库表，从如何保护数据库完整性到如何提高数据库的性能，从数据库的安全机制到并发事务控制，从数据库设计开发的常用模式到应用程序的数据访问策略，既有理论又紧扣实践。阅读本书的过程，就是把一些以前模糊地知道，但又觉得很难运用的理论实实在在地运用到实践中的过程。 　　虽然本书是针对SQL Server这个特定数据库平台来阐述理论和实践的，然而，本书所体现的思想和方法，完全可以运用到其他关系数据库平台上。.. 　　翻译的时间很紧，如果没有家人的支持和理解，很难想象如何完成这项工作。 　　感谢人民邮电出版社图灵公司很好地推动了这本书的翻译工作。另外，图灵公司的论坛上丰富的资料和活跃的讨论也使我们眼界大开，受益良多。 　　翻译工作并非阐述自己的思想，翻译的第一要务是忠实地传达原著者的思想。虽然无法自由地表达自己的想法，然而，翻译的快乐就在于：使另一个人的好想法能让更多的人了解。当然，由于时间紧张，译者水平有限，错误粗糙之处相信不在少数，敬请广大读者批评指正。 　　感谢我的妻子魏萍，你容忍我一吃完饭就坐到计算机前。谢谢女儿程灵馨，在爸爸不能陪你玩时，5岁的你居然也表示理解。谢谢作者Louis Davidson，你耐心地回答了我的问题。 　　程桦 　　感谢我的未婚妻张艳，是你的鼓励和体贴让我在寒冷的冬日伏案不辍。还要感谢我的家人，你们殷殷的期盼让我产生了对知识的不渝追求。... 　　张绪业 　　2009年5月 　　 前言 　　我经常扪心自问，“为什么要做这件事？为什么还要写新版本？这值得吗？如果我抛开书去打任天堂游戏机，我是不是能帮超级玛丽快点把公主救出来？”在微软MVP 2008年峰会上，这些问题都由一位MVP帮我回答了。他感谢我写了这本书，说他曾经试着读点这方面的大学教材，但那些书都太难了，读不太懂。. 　　“喔，是的，”我想，“那是我最开始要写这本书的原因。”当我最早开始设计数据库时，我从几位伟大的导师那里学到了不少东西，但是，当我想进一步深入研究时，我开始寻找数据库设计方面的材料，但没找着多少。我找到的最好的一本书是Chris Date的An Introduction to Database Systems（Addison Wesley，2003），然后我读了自己能读懂的部分。然而，我很快就有点晕头转向，没法做到一旦理解了概念之后，就能很好地将关于设计的理论转换到真正的、同时较为简单的设计过程中去。在我所使用的Chris和其他人的教材中，很明显，创建关系模型这件事包含了太多理论，甚至是数学知识。 　　如果你想要成为一名理论家，那Chris的书就是必读的，当然，除此之外还有很多可以参考的书（最好去看看http://www.dbdebunk.com/books.html，你会找到更多的书）。问题在于，这些书大多数都包含了太多的理论，超出了一般实践工作者所需了解的（或者愿意花时间去读的）内容，并且它们没有真正地深入到实际数据库系统的实现中去。我的书的目标很简单，那就是填补这个空白，在大学教材与通常针对SQL Server所写的、纯粹面向实践的书之间架起一座桥梁。我的目的不是顶替这些书，完全不是，在我的书架上有很多这样的书。本书更像是一本面向技术的书，而不是讲解SQL Server功能的使用手册。我将介绍关系引擎的大多数典型功能，教给你使用它们的技术。然而，我不能说这是你书架上需要的唯一一本书。 　　如果你有本书以前的版本，你可能会问为什么还需要这个新版本，我了解你的感受。我花了大量时间找出应该买这个新版本的理由，而这个理由并不那么明显——那就是，我现在涵盖了2008的所有功能。很明显，这只是部分原因，最重要的是，我一直在努力加入更多新内容让你的工作更轻松。我加入了一章（第7章）介绍开发模式，每一章中也都加入了大量新材料，从而能帮你改进数据库设计。 　　诗人和剧作家奥斯卡王尔德曾经说过：“只有年轻人才会无所不知。”现在回头看时有点后悔，自己在写第一本书Professional SQL Server 2000 Database Design之前，以为自己什么都知道。正是那种无知和放纵不羁的热情，才让我有勇气写下第一本书。最后，我确实完成了第一本书，它之所以还不错，主要归功于技术编辑给予的批评。并且，如果我没有最初那种驱使我写完书的热情的话，我也不可能写这本书的第四版。无论如何，如果你花几周的时间逐章逐节地比较了这些书的每个版本的话，你会发现这是个内容逐步丰富的过程，而且作者也在逐步成熟。 　　过程的逐步丰富和作者的逐渐成熟都有其原因。一个原因是过去两个版本以来我所碰到的编辑：首先是Tony Davis，现在是Jonathan Gennick。他们两人对我的文风都多有指摘，并且他们把本书的结构调整得很棒。另一个原因可以简单地归结为经验，因为从我开始写第一版以来已经过了8年。但是，书中所用的材料之所以有进步，最大的原因还是它们经过了检验。一方面我在对别人贡献着自己的好评论，另一方面我也收到了大量关于如何改进的反馈（其中一些评论可不那么友善）。我非常用心地倾听，从书发布那天开始就记一系列笔记。对于我能用得上的任何反馈，我都会感到很高兴。可以用电子邮件联系我（louis@drsql.org），如果你愿意也可以在我的网站（drsql.org）留下匿名反馈。你可以在网站上找到一个附录，里面含有我希望自己在写这本书时就了解了的材料。 　　数据库设计的目的 　　数据库设计的目的是什么？你到底为什么要关心这事？主要的原因是设计良好的数据库用起来很简单，因为所有东西都在其应处于的逻辑位置上。这非常像一个收拾得很好的橱柜，如果你需要红辣椒粉，直接到调味品搁架的红辣椒粉那格就能取到，这就比到处乱找要强得多。但是，许多系统组织得一团糟。即使每件东西都有一个分好的地方，如果找起来很困难，那件东西也就没啥价值了。想象如果一本电话簿完全没有排序会如何？或者，编排字典的时候把词任意放在文字中能放下的地方又会如何？数据库如果组织良好的话，即使要写一两个联结，你也可以靠本能就知道去哪里获取需要的数据。我的意思是，说到底，这难道不是件很有趣的事吗？.. 　　你也可能吃惊地发现，数据库设计是件相当简单的任务，不像听起来那么困难。与随着项目进行而拼凑数据存储相比，要做好这件事需要在项目一开始多花些时间，但是，在项目的整个生命周期中，这样做能获得相应回报。要想正确地进行数据库设计，我们面对的最具挑战性的问题是：与不做设计相比，正确地设计数据库会花更多的时间（在项目计划会议上，关于时间的争论经常发生）。因为数据库设计没有什么可见的东西来让客户感到赏心悦目，因此这一阶段经常会被压缩，目的就是让事情看起来进行得较快。对于普通客户而言，即使是最没有挑战性、最不让人感兴趣的用户界面也比最漂亮的数据模型要吸引人得多。虽然一般说来，数据才是投资创建系统的最终原因，但是，用户界面编程往往占据了中心地位。并不是说你的同事没有注意到一个糟糕的数据模型与一个漂亮的数据模型之间的区别，他们确实注意到了，但是，当程序员需要编码时，往往会顾不上考虑如何能正确地存储数据。我希望自己知道这个难题的答案，因为要是有这个答案，我的书会卖出一百万本。本书将努力提供一些技术和过程，帮助你进行数据库设计，力求对新手清晰易懂，对老练的专家也有所助益。 　　这个设计和架构数据存储的过程与数据库安装和管理的角色并不相同。例如，作为数据架构师的角色，我很少去创建用户、执行备份，或者去设置复制与集群。我很少谈及这些任务，它们被认为是管理工作，由DBA角色担当。既是开发人员又是DBA的人并不罕见（实际上，如果你在小公司工作，你会发现自己担当了多个角色，以至于不堪重负），但是，如果你能将自己的思维与偏重实现的角色相分离，从而使你能更多地思考数据有多难用，那么一般说来，你设计出的东西会好很多。对许多情况而言，数据库设计没有看起来那样困难。 　　注解为安全起见，我要澄清一件事：如果你做过任何编程工作的话，毫无疑问，你会反对本书中的某些观点和意见。我完全同意本书不是什么Katmai 的圣路易斯 福音书。我的意见和观点来自于超过16年对数据库的学习、在数据库上的工作，并且由来自于许多不同的人、书、大学课堂和研讨会的知识所补充。我在“致谢”一节已经感谢了其中的许多人，但是，我忘掉的人名也数以百计，我脑中铭刻的某些知识精华就来自于他们。本书所展示的设计方法是所有这些思想的集合。我希望本书能被看作是个有用的学习工具。通过阅读本书和其他人的著作，再实践你自己的想法，你将会总结出自己的方法论，它会适合你自己，并使你成为成功的数据库设计人员。 　　本书的结构 　　本书由如下各章组成。 　　第1章：数据库概念简介。该章提供了对关键术语和概念的简要概览。 　　第2章：数据建模语言。该章的作用是介绍数据架构师的主要工具——模型。该章详细介绍了一种建模语言——IDEF1X，因为它是本书中用于展示数据库设计的建模语言。还介绍了其他几种常见的建模语言，因为某些读者或者出于偏爱、或者由于公司的要求会使用这些类型的模型。 　　第3章：概念阶段数据建模。在概念阶段数据建模中，我们的目标是讨论这样的过程：引入顾客的需求集合，将表、列、关系和业务规则放入数据模型格式中相应的地方。 　　第4章：规范化过程。数据库设计过程的下一步是规范化。规范化的目标是将表、列、关系和业务规则的集合格式化为每个值只在一个地方存储、每张表只代表一个单一实体的形式。在最初几次进行规范化时，这个过程会感觉不太自然，因为你不用琢磨如何使用数据，却必须琢磨数据本身以及结构会如何影响数据的质量。然而，一旦你掌握了规范化，那么，不以规范化的方式存储数据就会让人觉得不舒服。 　　第5章：实现基础的表结构。在数据库设计过程中，这是第一个要启动SQL Server，开始写脚本来构建数据库对象的时间点。该章讨论了构造表（包括为列选择数据类型）及关系，其中提到了实现后的结构可能与我们在规范化过程中得到的模型不一致的问题。 　　第6章：保护数据的完整性。除了要将数据安排在表和列中之外，也需要实现其他业务规则。在SQL Server中，保证数据完整性条件得以满足的第一条防线由CHECK约束与触发器构成，因为用户无法轻易绕开由约束和触发器进行的验证。这一章还讨论了其他几种保护数据的方法，它们可以用存储过程和客户端代码来实现。 　　第7章：模式和查询技术。除了设计表时的各种基本技巧之外，我们还利用几种技巧来构成常见的数据/查询接口，从而方便未来的查询和使用。该章讨论了几种常见的、有用的模式，同时也观察了某些人需要使用的一些模式——有些查询需求的接口实现对你来说非常困难，而这些模式能使它们变得更简单些。 .　　第8章：数据访问安全。这些日子以来，安全问题几乎在每个程序员的头脑中都占据了很重要的位置。该章讨论了用来在系统中实现数据安全的某些策略，比如使用视图、触发器、加密，甚至使用SQL ServerProfiler等。 　　第9章：表结构与索引。该章展示了如何在SQL Server中建立表结构的基础知识，以及某些对数据进行索引以获得更好性能的策略。 　　第10章：并发编程。数据库设计和实现过程的一部分是不仅要考虑结构，而且还要考虑如何在多个用户之间最大化资源的利用率。该章描述了几种策略，它们都与如何在你的数据访问和修改代码中实现并发相关。 　　第11章：数据访问策略。该章讨论了关于编写代码来访问SQL Server的许多概念和问题。比较了即席SQL与存储过程（包括两者面对的所有风险和挑战，比如计划的参数化、性能、开发投入、可选参数、SQL注入等），同时也讨论了T-SQL还是CLR对象更好，其中包括用CLR来编码不同类型的对象的示例。有关CLR的材料由Kurt Windisch提供，可以下载的CLR示例代码也由他提供。 　　附录A：Codd的RDBMS十二法则。本附录介绍了Codd关于数据库应该如何实现的创新的十二条原则。随着硬件的发展，我们离实现他的梦想越来越近。 　　附录B：标量数据类型参考。本附录介绍了可以被合法地当作标量类型的所有类型，为什么要用它们，以及它们的实现信息和其他细节。 　　再一次强调，给我反馈时不用犹豫，任何时候都不要犹豫（只要你不在早上3点给我打电话就行）。对任何章节，我都将努力改善大家发现还有所欠缺的地方，并将改善后的内容发布到我的博客上（http://sqlblog.com/blogs/louis_davidson），其标签为DesignBook，同时也会发布到我的网站上（http://drsql.org/ProSQLServerDatabaseDesign.aspx）。如果有什么新的想法或者找到了一些错误，或者有额外的资料，我都会将其添加在这两个地方。因为这是一本书，而不再是零零星星的资料，这两处是我能想到并选来发布信息的地方。... 　　 序言 　　数据库设计是Louis和我都热衷的事情。今年秋季，我将幸运地和我的朋友Louis Davidson登上同一个舞台。我们将在DevLink会议上演讲，地点是Louis的家乡Nashville，然后，在西雅图的PASS上我们也将同台演讲。在这两次演讲中，我们都将针对数据库设计这个题目开展讨论和辩论，并探讨对以数据为中心的应用来说数据库设计有多关键。. 　　数据库设计是门科学也是门艺术。规范化应该说是门科学，而确定实体的范围则是一门艺术，需要具有与各种数据库打交道的经验才能学到手。优雅的解决方案都有一种简单的美。Louis不止是位作者和数据库设计人员，也是一位大师级技师。在本书中，你会发现字里行间都隐藏着作者的呼吁——改善你的技能，精心雕刻出能够经受时间考验的数据库，创造一个能让开发人员充分施展拳脚的、虚拟的数据世界。.. 　　数据库设计是每个以数据为中心的应用的基石。一个优雅的数据库设计使得数据一目了然、容易查询，并且使用有效的、基于集的查询将开发人员武装起来，使他们获得成功。但是，如果数据库设计就很糟糕，则无论多少代码也无法补偿，也无法为数据库加上缺失的功能。对任何以数据为中心的应用来说，没有什么角色比数据建模人员这个角色更为重要。用户界面换来换去，但是，即使经历了好几代应用编程语言，数据仍然存在着。数据库架构上犯下的错误迟早会被未来的程序员诅咒，即使他现在还未出生，即使他用的是现在还没发明的语言和工具。在我的好朋友Louis的指导下，多花一点时间来润色你的数据库设计，绝对是件值得的事。 　　因此，欢迎你阅读本书，这是Louis针对软件世界最重大的工作所写的战地指南的第三版。能够为本书作序我感到无比愉快。... 　　Paul Nielsen 　　SQL Server MVP 　　 媒体评论 　　“跟本书的2005版一样，我认为Louis的这本书写得非常好，信息量极其丰富而且实践性强。阅读过程中，你会觉得是在跟作者讨论问题。我喜欢这本书，还因为它有自己的观点，而非从在线图书中照搬过来……” 　　—— Amazon读者评论...