SQL编程风格(世界级大师的SQL编程规范)
点击看大图基本信息
- 原书名： Joe Celko's SQL Programming Style
- 原出版社： Morgan Kaufmann
- 作者： (美)Joe Celko [作译者介绍]
- 译者： 米全喜
- 丛书名： 图灵程序设计丛书.数据库系列
- 出版社：人民邮电出版社
- ISBN：9787115185822
- 上架时间：2008-9-4
- 出版日期：2008 年10月
- 开本：16开
- 页码：194
- 版次：1-1
- 所属分类：
计算机 > 数据库 > SQL语言
编辑推荐
世界级大师的SQL编程规范.
讲述如何编写标准、高效、易于维护的SQL代码..
教你像优秀的SQL程序员那样思考...
推荐阅读
内容简介回到顶部↑
作译者回到顶部↑
本书提供作译者介绍
Joe Celko世界著名的数据库专家，曾经担任ANSI SQL标准委员会成员达10年之久，他也是世界上读者数量最多的SOL图书作者之一。他曾撰写过一系列专栏，并通过他的新闻组支持了数据库编程技术以及ANSI／ISO标准的发展。除本书外，他还撰写了多部SQL经典著作，包括《SQL解惑（第2版）》（人民邮电出版社，2008）和《SOL权威指南》（即将由人民邮电出版社出版）。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
第1章 名称与数据元素
1.1 名称
1.1.1 注意名称长度
1.1.2 在名称中避免使用所有特殊字符
1.1.3 避免使用引号分隔标识符
1.1.4 实施大写规则以避免大小写区分问题
1.2 遵循iso-11179标准命名规范
1.2.1 sql的iso-11179
1.2.2 抽象级别
1.2.3 避免使用描述性前缀
1.2.4 制定标准化的后缀
1.2.5 表和视图名称应当是遵循业界标准的、集合、类或复数名称
1.2.6 相关名基本上也要遵循与其他名称相同的命名规则
1.2.7 关系表名应当是常用描述术语
1.2.8 元数据模式访问对象的名称可以包含结构信息
1.3 命名数据元素时遇到的问题
1.3.1 避免模糊名称
1.3.2 避免名称在不同的地方改变
1.3.3 不要使用专有暴露的物理定位符
第2章 字体、标点和间距
1.1 名称
1.1.1 注意名称长度
1.1.2 在名称中避免使用所有特殊字符
1.1.3 避免使用引号分隔标识符
1.1.4 实施大写规则以避免大小写区分问题
1.2 遵循iso-11179标准命名规范
1.2.1 sql的iso-11179
1.2.2 抽象级别
1.2.3 避免使用描述性前缀
1.2.4 制定标准化的后缀
1.2.5 表和视图名称应当是遵循业界标准的、集合、类或复数名称
1.2.6 相关名基本上也要遵循与其他名称相同的命名规则
1.2.7 关系表名应当是常用描述术语
1.2.8 元数据模式访问对象的名称可以包含结构信息
1.3 命名数据元素时遇到的问题
1.3.1 避免模糊名称
1.3.2 避免名称在不同的地方改变
1.3.3 不要使用专有暴露的物理定位符
第2章 字体、标点和间距
译者序回到顶部↑
数据库发展到今天，可以说是无处不在。作为程序员，我们或多或少都需要与数据库打交道。在设计数据库或使用SQL编程的时候，我们是否注意到了SQL与其他过程化或面向对象编程语言的差异?我们是否有一套可行的编程规范?我们考虑了代码的可读性、可移植性和性能吗?我们是在以SQL的思考方式使用SQL吗?.
按照本书作者Joe Celko的观察，很多人都还做不到，而这也正是编写本书的目的。本书的第1～2章介绍了命名规范和代码的版式。第3～5章介绍了数据定义语言，说明了在设计键、编写约束、选择数据类型、设置默认值时应当注意的事项，并介绍了测度论、编码方案及其在数据库系统设计中的应用。第6～8章介绍了数据操作语言，从可读性、可移植性和性能等方面说明了编写程序和使用视图、存储过程时的注意事项。第9章和第10章介绍了SQL中的思考方式和试探法。这本书的书名虽然是编程风格，但它更像是一本SQL编程指导书。作者从事SQL咨询工作20多年并长期活跃在SQL社区，他知道程序员们经常犯什么错误，需要在哪些方面进行改进。本书通过大量的示例以及作者的见闻和亲身经历，详细说明了编程时应当遵守的规则——什么是应该做的，什么是不应该做的。这不是一本入门书，讲述的不是如何使用SQL编程的基础内容，但是通过对本书的学习，可以帮助我们更好地理解SQL的思考方式，从而设计出更好的数据库和SQL程序。..
人民邮电出版社最近引进了Joe Celko的几本著作，有这样一位大师的指引，必然会提高我们对SQL的理解和应用水平。非常感谢图灵公司几位编辑对我的信任，将其中两本的翻译工作交给了我。本书篇幅不大，但是涉及的内容较广，译者在翻译过程中尽量使得译文准确、流畅，但其中难免有疏忽之处，欢迎读者批评指正，请将意见发送到miquanxi@hotmail．com。...
译者
2008年6月
按照本书作者Joe Celko的观察，很多人都还做不到，而这也正是编写本书的目的。本书的第1～2章介绍了命名规范和代码的版式。第3～5章介绍了数据定义语言，说明了在设计键、编写约束、选择数据类型、设置默认值时应当注意的事项，并介绍了测度论、编码方案及其在数据库系统设计中的应用。第6～8章介绍了数据操作语言，从可读性、可移植性和性能等方面说明了编写程序和使用视图、存储过程时的注意事项。第9章和第10章介绍了SQL中的思考方式和试探法。这本书的书名虽然是编程风格，但它更像是一本SQL编程指导书。作者从事SQL咨询工作20多年并长期活跃在SQL社区，他知道程序员们经常犯什么错误，需要在哪些方面进行改进。本书通过大量的示例以及作者的见闻和亲身经历，详细说明了编程时应当遵守的规则——什么是应该做的，什么是不应该做的。这不是一本入门书，讲述的不是如何使用SQL编程的基础内容，但是通过对本书的学习，可以帮助我们更好地理解SQL的思考方式，从而设计出更好的数据库和SQL程序。..
人民邮电出版社最近引进了Joe Celko的几本著作，有这样一位大师的指引，必然会提高我们对SQL的理解和应用水平。非常感谢图灵公司几位编辑对我的信任，将其中两本的翻译工作交给了我。本书篇幅不大，但是涉及的内容较广，译者在翻译过程中尽量使得译文准确、流畅，但其中难免有疏忽之处，欢迎读者批评指正，请将意见发送到miquanxi@hotmail．com。...
译者
2008年6月
前言回到顶部↑
本书不是一本SQL入门书。真的，如果你需要的是学习如何使用SQL进行编程，有其他更好的书。本书应该是你买的第二本书，而不是第一本。.
本书假设你已经能够编写一定水平的SQL，并且希望进一步提高。如果你想要学习SQL编程技巧，可以买一本我编写的Joe Celko's SQL for Smarties(2005年第3版)。在本书中，我想教给读者的，是如何以逻辑和说明性的方式编程，而不是以过程化或面向对象的方式——也就是要“用查询的思维看数据库”。
绝大多数SQL程序员都是在有了几年的过程化语言或面向对象语言编程经验之后才开始接触SQL的。他们拿到某个SQL产品，然后只能自学，使用的书都是“SQL for Brain-Dead Morons(SQL傻瓜书)”、“Learn SQL in Ten Easy Lessons or Five Hard Ones(用10节容易的或5节复杂的课程学会SQL)”或其他更烂的书。
这太荒唐了!成为熟练的木匠或厨师都至少需要5年。为什么你会相信人们在一个周末内就能变成SQL高手?他们会变成糟糕的SQL程序员，只会使用本地SQL产品中的方言，并带有他们从前使用的编程语言的浓重口音。你可能需要读一下Peter Norvig写的“Teach Yourself Programming in Ten Years”一文(www．norvig．com／21—days．html)或Fred Brooks写的“No Silver Bullets”(Computer，20(4)：10—19，1987年4月)，以了解真实情况。
可怕的是这些人常常不知道自己是拙劣的程序员。一个极端情况是，整个公司的人都做得很差，他们从来没有见过高手。另外一个极端情况是，如果某人尝试告诉他们所存在的问题，他们会极力辩解或恼羞成怒。看看SQL新闻组中的帖子，你会发现许多程序员只是需要对问题立即得到一个权宜解答，并不想真正获得一个长期有效的解决方案。
如果这些是木工行业的新闻组，他们的问题将等同于“将螺丝钉敲进精致的家具时，使用什么样的石头最好?”如果有人告诉他使用一大块花岗岩，他们会很高兴，但是如果你告诉他们使用螺丝刀，他们就愤怒了。
你可能需要阅读由Justin Kruger和David Dunning(康奈尔大学心理学系)写的有关这个现象的一篇文章“Unskilled and Unaware of It：How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments”(www．apa．org／joumals／psp／psp7761121．pdf)。或者是看一下美国高中生在数学和自然科学的自我评估结果和实际结果的对比，这是布什政府的No Child Left Behind Act(《不让一个儿童落后法》)的一部分。
本书的目的
当那些过时的程序员当道的时候，我们这些老家伙们是如何成为更好的程序员的呢?在20世纪70年代末掀起结构化编程革命的时候，对我们最有帮助的是由Henry Ledgard和他在MIT的一些同事编写的一系列名为“[PASCAL
本书假设你已经能够编写一定水平的SQL，并且希望进一步提高。如果你想要学习SQL编程技巧，可以买一本我编写的Joe Celko's SQL for Smarties(2005年第3版)。在本书中，我想教给读者的，是如何以逻辑和说明性的方式编程，而不是以过程化或面向对象的方式——也就是要“用查询的思维看数据库”。
绝大多数SQL程序员都是在有了几年的过程化语言或面向对象语言编程经验之后才开始接触SQL的。他们拿到某个SQL产品，然后只能自学，使用的书都是“SQL for Brain-Dead Morons(SQL傻瓜书)”、“Learn SQL in Ten Easy Lessons or Five Hard Ones(用10节容易的或5节复杂的课程学会SQL)”或其他更烂的书。
这太荒唐了!成为熟练的木匠或厨师都至少需要5年。为什么你会相信人们在一个周末内就能变成SQL高手?他们会变成糟糕的SQL程序员，只会使用本地SQL产品中的方言，并带有他们从前使用的编程语言的浓重口音。你可能需要读一下Peter Norvig写的“Teach Yourself Programming in Ten Years”一文(www．norvig．com／21—days．html)或Fred Brooks写的“No Silver Bullets”(Computer，20(4)：10—19，1987年4月)，以了解真实情况。
可怕的是这些人常常不知道自己是拙劣的程序员。一个极端情况是，整个公司的人都做得很差，他们从来没有见过高手。另外一个极端情况是，如果某人尝试告诉他们所存在的问题，他们会极力辩解或恼羞成怒。看看SQL新闻组中的帖子，你会发现许多程序员只是需要对问题立即得到一个权宜解答，并不想真正获得一个长期有效的解决方案。
如果这些是木工行业的新闻组，他们的问题将等同于“将螺丝钉敲进精致的家具时，使用什么样的石头最好?”如果有人告诉他使用一大块花岗岩，他们会很高兴，但是如果你告诉他们使用螺丝刀，他们就愤怒了。
你可能需要阅读由Justin Kruger和David Dunning(康奈尔大学心理学系)写的有关这个现象的一篇文章“Unskilled and Unaware of It：How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments”(www．apa．org／joumals／psp／psp7761121．pdf)。或者是看一下美国高中生在数学和自然科学的自我评估结果和实际结果的对比，这是布什政府的No Child Left Behind Act(《不让一个儿童落后法》)的一部分。
本书的目的
当那些过时的程序员当道的时候，我们这些老家伙们是如何成为更好的程序员的呢?在20世纪70年代末掀起结构化编程革命的时候，对我们最有帮助的是由Henry Ledgard和他在MIT的一些同事编写的一系列名为“[PASCAL
媒体评论回到顶部↑
“Joe Celko是当今数据库界最著名的代表之一，他已经写了不少SQL编程的畅销书。但是。本书非常与众不同，它将教你如何转变思维方式，以逻辑和说明性的方式编程。成为一流的SQL开发人员。”
——sQL-Server-Performance.corn
——sQL-Server-Performance.corn
书摘回到顶部↑
第1章名称与数据元素
1.1 名称
以前，每个程序员都有一套自己的命名规范。但是，他们常常都太有创造性了。我特别喜欢举的一个例子是，有一个人使用某类主题词作为他的COBOL段名：一段程序可能使用国家名，另外一段可能使用花卉，等等。即使就程序员而言，这显然也是很奇怪的行为，但是很多程序员的个人命名系统只有他们自己明白，别人都无法理解。
例如，我使用的第一个FORTRAN版本只允许6个字母的名称，所以我变得善于使用和发明6个字母的名称。开始编程时使用弱类型或无类型语言的程序员们都喜欢使用匈牙利表示法（参见Leszynski和Reddick）。老的习惯很难放弃。
当软件工程变成规范后，每个公司都制定了自己的命名规范，并使用某种数据字典实施这些规范。使用最广泛的一套规则可能要算是由美国国防部建立的MIL STD8320.1，但它在联邦政府之外却从未流行起来。这与先前缺乏有效组织的体系相比，已经有了很大进步，但是每个公司都有很大的不同：有些对于名称构造有正式的规则，而另外一些则只是将赋予数据元素的第一个名称登记一下。
现在，我们有了ISO-11179标准，它正变得越来越普遍，是某些政府工作所需要的，并且正在被放入到数据储存库产品中。一些工具和大量标准化编码方案也被放入到了这个标准中。考虑到这一点，并考虑到XML是一种标准交换格式，ISO-11179在今后将成为元数据参考的方法。
……
1.1 名称
以前，每个程序员都有一套自己的命名规范。但是，他们常常都太有创造性了。我特别喜欢举的一个例子是，有一个人使用某类主题词作为他的COBOL段名：一段程序可能使用国家名，另外一段可能使用花卉，等等。即使就程序员而言，这显然也是很奇怪的行为，但是很多程序员的个人命名系统只有他们自己明白，别人都无法理解。
例如，我使用的第一个FORTRAN版本只允许6个字母的名称，所以我变得善于使用和发明6个字母的名称。开始编程时使用弱类型或无类型语言的程序员们都喜欢使用匈牙利表示法（参见Leszynski和Reddick）。老的习惯很难放弃。
当软件工程变成规范后，每个公司都制定了自己的命名规范，并使用某种数据字典实施这些规范。使用最广泛的一套规则可能要算是由美国国防部建立的MIL STD8320.1，但它在联邦政府之外却从未流行起来。这与先前缺乏有效组织的体系相比，已经有了很大进步，但是每个公司都有很大的不同：有些对于名称构造有正式的规则，而另外一些则只是将赋予数据元素的第一个名称登记一下。
现在，我们有了ISO-11179标准，它正变得越来越普遍，是某些政府工作所需要的，并且正在被放入到数据储存库产品中。一些工具和大量标准化编码方案也被放入到了这个标准中。考虑到这一点，并考虑到XML是一种标准交换格式，ISO-11179在今后将成为元数据参考的方法。
……
)
加载中...
