1.1 Preface
At present there is a phenomenon in the software circle, that is: DBAs do not know how to write Pl/sql, and developers write a variety of, and inefficient. So many drawbacks have been caused:
1. Poor readability. It takes longer to read a program written by someone else than to write a program, and not only do people not understand it, but they can't understand it for a long time.
2. Poor maintainability. The longer the program is written, the worse it becomes, like the laceless cloth of the lazy woman, and the long stink.
3. Portability is poor. Today, write a set of Oracle, tomorrow when the SQL Server to write a set, a large number of database developers in the process of the misery of the repeated low-level labor ...
4. Poor efficiency and performance. A stored procedure or SQL execution efficiency simply makes you feel hopeless about time, and you quickly understand what relativity is.
1.2 Programming Specification Overview
In fact, in order to unify the naming conventions and programming specifications for database design in the process of software development, some formal IT companies will develop some naming and programming specifications for database objects.
Otherwise, you write your I write my, each other incompatible, do not understand each other, even to the end even they do not understand, such an experience that everyone has ever met.
For example, the following simple code, you see it? Even if I know for a moment, do you understand a Yinianbanzai? Even if your memory is superior, must also forget, isn't it?
a:=1;b:=2; SeLeCT username from EmPLOyee where id=a and type=b;
If you change to the following wording, I believe that people who know a little bit of database should see it.
Vid:=1; --a as ID
vtype=2; --b for type
SELECT username from employee WHERE Id=vid and Type=vtype;
1.3 Writing Specifications
Ugly writing norms are not only less readable, but also give people a sense of distance, that is, you are not a warrior ah, and good writing norms give people the enjoyment and artistic experience.
1.3.1-Case Style
Rule 1.3.1.1
All database keywords and reserved words are capitalized; The case style for fields and variables is described in detail in 1.4.
1.3.2 Indent Style
Rule 1.3.2.1
The program block is written in indented style to ensure the code is legible, the style is consistent and the number of indents is 2/4.
You must use a space and do not allow the TAB key to be used. To avoid using a different editor to read the program, because the TAB key to set a different number of spaces caused the program layout is not neat.
Rule 1.3.2.2
When the same statement requires more than one row, the other keywords for each row are right-aligned with the keywords in the first line.
IF flag=1 THEN
SELECT Username--indents 4 spaces compared to the previous line
Into Vuserinfo--into right-aligned with select
From UserInfo--from to the right alignment with select
WHERE Userid=:iuserid; --where and select to align Right
End IF;
1.3.3 Space and line wrapping
Rule 1.3.3.1
Multiple statements are not allowed to be written on one line, that is, a single statement is written on a line.
Rule 1.3.3.2
Avoid writing complex SQL statements to the same line, suggesting that you want to wrap them at the keyword and predicate.
Rule 1.3.3.3
There must be a blank line between the relatively independent pieces of the program.
BEGIN and end independently
Rule 1.3.3.4
An expression that is too long should be wrapped at the lower-priority operator, with the operator or keyword at the top of the new line. The new line should be indented properly to make the layout neat and the statement readable.
When mixed with different types of operators, it is recommended that you use parentheses for isolation to make the code clear.