MSSQL网页编程之从门客到年夜厨
Cluster/NDB高冗余的存储引擎，用多台数据机器联合提供服务以提高整体性能和安全性。适合数据量大，安全和性能要求高的应用从门客到年夜厨－书评《Oracle功能优化手艺内情》
实在fenng之前在CSDN的程序员杂志上也作过这本书的书评，事先看到谁人书评的时分，这本书还没有买，只是方才下载完英文的电子版。看到Chapter2就以为很不错的一本书，因而跑到china-pub上买了一本，这类心境就比如关于本人由衷喜好的CD那是必定要买正版的，别的无关紧要的嘛，那就挣一只眼闭一只眼，因陋就简已往算了。
借用fenng关于这本书的一句批评，“读过这本书，大概良多Oracle7/8时期的DBA会感应懊丧：由于会发明他们已往以为准确的一些优化办法和头脑竟然是毛病的！”。
怎样，单单这句话是否是已充足吸引你了，要晓得错一次不是你的错，可是在有了这本书以后，你竟然还错第二次，那就是你的成绩了。
静下心来一页一页地读一本手艺书本，说假话，是很难的。
常人城市在入手下手摸到一本旧书的时分，非常冲动，并且充斥雄心勃勃必定要把这本书看完，了局常常是看到半途不太感乐趣的中央就以为没甚么意义了，但又常常会以为是否是跳过这一章节又会遗漏甚么主要环节，因而在徘徊犹豫，七上八下，疾苦失望中蹉跎了光阴，扫除扫除抽屉乃至壁橱，是否是一堆买了今后却没有看完的书？
可是，光荣的是，这本书不会。
这本书每个章节的入手下手都有几个曲解和现实的对照，在曲解部分将会看到良多之前我们一向以为是真谛的调优实际和办法，而现实部分则对这一曲解举行了批判，同时对现实的论述也就是这一章节的主要内容。
书的章节散布也是一个值得推介的中央，夙昔到后，是作为一个DBA面临调优的义务时，应当顺次举行的部分。首章先容了守候事务和跟踪功能成绩的办法，这是调优的基本实际和基本手腕，接上去的第二章则是使用程序的优化，大概人人都晓得，大概另有人不晓得，实在优化的80％的事情都是在使用程序部分，这也是作为一个DBA事情中的难点，程序不是我们编写的，大概先期的计划我们都基本没有介入，比及项目上线了，才发明功能成绩，这在国际的良多项目上太罕见了，我们能作的是甚么？我们必要找到招致功能成绩的最主要的中央，基础上都是程序的成绩，我们提出计划，也许会被承受，也许不会，由于这个时分再往修正程序已太迟了，可是作为DBA，我们应当尽到本人的天职，应当提出办理计划，即便此次没法依照这个计划修正，那末下次大概就能够了。以是，DBA不要埋怨程序员这个SQL写得差，谁人SQL写得差，由于优化SQL不是程序员得事情，而是我们DBA得事情，假如年夜多半得程序员写的SQL都很差，那末大概只标明了一个成绩，那就是你不是一个很称职的DBA，由于给程序员培训也是DBA的一个职责。
仿佛有些切题，那末我们再返来言回正传。
假如使用程序在各种情形下没法调剂了，大概说已没法再进一步伐整了，那末我们进进下一步，实例和数据库优化，这内里包含了SGA各个部分的优化，同时包含了数据库物理存储布局的优化。接上去，书中又论述了别的的一些特别优化，和情况优化，这包括了并行，I/O，操纵体系情况设置，等等。
这本书读上去的感觉，就比如是一顿悉心烧制的年夜餐，每道菜都很优美而没有一点儿清淡，每道菜都值得你在尝完今后再仔细地回味，不要妄图很快就晓得一切的菜的作法，可是，每次当你碰着要进补的时分，你又恰好会再想起之前你吃过这么一道菜，你会忍受不住想往再尝一尝，此次你对这道菜的印象就又深入了些，然后就是下一次再下一次。。。当你闭上眼睛，这顿丰厚的晚宴在你的长远出现，关于每道菜你都明晰地晓得放了几盐，加了几料，蒸炸烹炒了多长工夫的时分，那末祝贺你，你已从门客退化为年夜厨，已是一个大家级的人物了。
最初，仍是要发一些怨言，固然本书翻译的已不错了，基础上没有使人哭笑不得的毛病，可是在念书的过程当中仍是会发明一些成绩。
举个例子，有个小章节的标题是“如何不编写SQL”，事先看到的时分，其实是不分明，不要往写SQL了？DBA不该该往写SQL？持续往下看，才晓得，哦，本来是不该该写如何的SQL，也就是应当制止编写SQL时的哪些怀习气。厥后查了原文，发明是HowNottoWriteSQL，想一想假如搜索枯肠直译的话，那末天然就是“如何不编写SQL”。
假如说下面的尚可忍耐，那末上面这句其实让人有些想哭。仍然是HowNottoWriteSQL这一章节，个中一段，“此查询其实不伶俐，但为了完全性，我们必需谈及它。不要为在from子句中没有一切表的一切毗连前提的select语句创建where子句的前提。”假如谁说三次之内就看懂了这句话，那末我其实很信服此人。原文是：Thisoneisno-brainer,butwehavetomentionitforthesakeofcompleteness.Donotbuildthewhereclausepredicatesforaselectstatementwithouthavingallthejoinconditionsforalltablesinyourfromclause.起首，此查询其实不伶俐？哪一个查询？不伶俐？明显应当是“这一条是不言而喻的，可是为了完全性，我们必需说起”，接上去前面那部分，翻译得就间接让人溃散了，我是看了10遍以上，最初仍是看原文看懂的。意义是，不要给一个select语句编写没有包括在from子句中呈现的一切表的一切毗连前提的where子句。说假话，我本人翻译的也很别扭，但我不是专业的翻译职员，这个，呵呵，能够包涵。
好的翻译请求信雅达，但愿今后可以看到更多更高质量的翻译作品吧。
2004年5月
Kamus
《Oracle功能优化手艺内情》/GajaKrishnaVaidyanatha等著/钟叫等译/机器产业出书社
2008年1月16号MySQLAB被Sun公司收购。而2009年，SUN又被Oracle收购。就这样如同一个轮回，MySQL成为了Oracle公司的另一个数据库项目。 外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。 其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。 如安全管理、备份恢复、性能监控和调优等，SQL只要熟悉基本操作就可以，只要程序设计部分只要稍加了解即可（如存储过程、触发器等）。 你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。 索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。 比如，MicrosoftSQLServer2008的某一个版本可以满足现在的这个业务的需要，而且价格还比Oracle11g要便宜，那么这一产品就是适合的。 至于淘汰的问题，只能说在你的项目周期之内，微软应该都不会倒闭。 其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。
页:
[1]