Programming specification of Dahua database

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.