the art of sql(一)

  Query Identification
  Stable Database Connections
  Strategy Before Tactics(Thinking Outside the Box)
  Problem Definition Before Solution
 OperationsAgainst Actual Data
  Set Processing in SQL
  Action-Packed SQL Statements
 Profitable Database Accesses
 Closeness to the DBMS Kernel
 Doing Only What Is Required
 SQL Statements Mirror Business Logic
 Program Logic into Queries
 Multiple Updates at Once
 Careful Use of User-Written Functions
 Succinct SQL
 Offensive Coding with SQL
 Discerning Use of Exceptions
 

There used to be a time when what is known today as "Information Technology" or IT was less glamorously known as "Electronic Data Processing." And the truth is that for all the buzz about trendy techniques, the processing of data is still at the core of our systemsand all the more as the volume of data under management seems to be increasing even faster than the speed of processors. The most vital corporate data is today stored in databases and accessed through the imperfect, but widely known, SQL languagea combination that had begun to gain acceptance in the pinstriped circles at the beginning of the 1980s and has since wiped out the competition. You can hardly interview a young developer today who doesn't claim a good working knowledge of SQL, the lingua franca of database access, a standard part of any basic IT course. This claim is usually reasonably true, if you define knowledge as the ability to obtain, after some effort, functionally correct results. However, enterprises all over the world are today confronted with exploding volumes of data. As a result, "functionally correct" results are no longer enough: they also have to be fast. Database performance has become a major headache in many companies. Interestingly, although everyone agrees that the source of performance issues lies in the code, it seems accepted everywhere that the first concern of developers should be to provide code that workswhich seems to be a reasonable expectation. The thought seems to be that the database access part of their code should be as simple as possible, for maintenance reasons, and that "bad SQL" should be given to senior database administrators (DBAs) to tweak and make run faster, with the help of a few magic database parameters. And if such tweaking isn't enough, then it seems that upgrading the hardware is the proper course to take. It is quite often that what appears to be the common-sense and safe approach ends up being extremely harmful. Writing inefficient code and relying on experts for tuning the "bad SQL" is actually sweeping the dirt under the carpet. In my view, the first ones to be concerned with performance should be developers, and I see SQL issues as something encompassing much more than the proper writing of a few queries. Performance seen from a developer's perspective is something profoundly different from "tuning," as practiced by DBAs. A database administrator tries to get the most out of a systema given hardware, processors and storage subsystem, or a given version of the database. A database administrator may have some SQL skills and be able to tune an especially poorly performing statement. But developers are writing code that may well run for 5 to 10 years, surviving several major releases (Internet-enabled, ready-for-the-grid, you name it) of the Database Management System (DBMS) it was written forand on several generations of hardware. Your code must be fast and sound from the start. It is a sorry assessment to make but if many developers "know" SQL, very few have a sound understanding of this language and of the relational theory.
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值