SQL statements reference specification

The company has standardized reference SQL statements, in particular, to be a note here.

Writing style

1. statement keywords should be all lowercase.

2. Reference character should be used with single quotes. Such as: update testable set idcol = 'abcd'.

3. Connector or operator or, in, and, =, <=,> =, +, - with a space before and after suitable. Otherwise easily lead to questions such as. For example, in the statement select a-b from table in, a, b are variables, spelling the statement, if a = 6, b = -3, the statement becomes a select 6--3 from table. - is regarded as SQL comments, results statement error.

4. not use "select * from ..." syntax, you must indicate the field name. That select col1, col2, ... from tablea where ...

5. Do not use "insert into table_name values ​​(?,?, ......)" syntax, uniform use of "insert into table_name (col1, col2, ......) values ​​(?,?, ... ...)".

When 6. SQL statement contains a join, the alias must be added to the table, the use of each field should be put on a table alias. I.e. select a.col1, a.col2, b.col3 from tablea a, tableb b where a.col4 = b.col5

7. avoid explicit or implicit type conversion. Compare, for example, in the where clause and an int type numeric columns.

8. must be added in parentheses around the subquery. select col1, col2 from tablea where col3 in (select col4 from tableb where col4> 0)

Should be performed only once a 9. execute SQL, if multiple statements should be performed separately, but must be kept in a transaction. Not once execute multiple statements separated by semicolons, so treatment is not clear.

Or it can be employed in place of 10. If, in the statement should not be used. in the statement of the elements shall not be more than 500, if exceeded, it should be split into multiple SQL statements. Do not use xx in ( '', '' ....) Or xx in ( '', '', '').

11. or connection conditions shall not exceed 500 should be split over multiple statements.

Performance Optimization

1. query should minimize read redundant data to reduce the number of records returned by the where clause.

2. If not in (in) operation in the statement, should be replaced by not exists (exists). In particular there was a clear difference between the search speed for both a large amount of data.

3 should not be used outside the connector. Low efficiency of the external connector.

The SQL statement can not be both a fetch and from the four tables above. Only for conditions associated with or without involvement of the filter table is not involved in access number calculation table; if 4 or must be associated with or more tables, should be addressed in the application server program, such as Java.

6 should be avoided and the group by order by sorting operations, sorting operations must be used as much as possible based on the indexed columns. Because a lot of sort operations affect system performance.

7. Comparative index column, should be avoided or not! =, Can be separated into several conditions. Because "not" and "! =" Not use the index. As is the index column col1, condition col1! = 0 can be split into col1> 0 or col2 <0.

8. The database should function, evaluate expressions written in the right logical operator. Because these operations will result in a table scan on a column, it affects performance.

9. In the where clause, if there are more filters, should be up to the number of the index column or filter in front of the recording conditions.

10. The function of connection can be achieved, not by sub-queries. For example: select name from customer where customerId in (select customerId from order where money> 1000). Should be replaced with the following statement: select name from customer inner join order on customer.customerId = order.customerId where order.money> 100. Or select name from customer where exists (select 1 from order where money> 1000 and customer.customerId = order.customerId) <note here: use exists efficiency depends on the degree of matching, inner join stable efficiency>

11. Multi-table query association, the following principles can be written, this is conducive to the establishment of an index to improve query efficiency. Format is as follows: select sum (t1.je) from table1 t1, table2 t2, table3 t3 where (equivalent conditions of t1 (=)) and (the condition of non-equivalence of t1) and (t1, t2 and associated conditions) and ( t2 is equivalent conditions) and (t2, the condition of non-equivalence) and (t2, t3 and associated conditions) and (t3, equivalent conditions) and (t3, the condition of non-equivalence).

Cross-database support

1. For the data format VO mapping database cross-database Java application advice:

1) integer fields: Field settings as Long Integer or

2) numeric field: If you need to use more accurate calculation decimal places, read, insert, update usage type BigDecimal

3) a character field: reading a String, and saved as a String, String to insert or update

4) field Time: The time of reading a String, insert or update when using middleware unitary.

3. You can not use the wildcard '[ac]%' in this form. Should be written as: select col1, col2 from table_name where col1 like '[a]%' OR col1 like '[b]%' OR col1 like '[c]%'

4. The length of the string interception function should use substr, 1 indicates the start position from the beginning. Db2 because the starting point is 1,0 substr will complain; used in the SqlServer database is a substring need to be converted.

The limits the number of records of the query result set not by select percent n and select top n.

6. join and on must match exactly, not on the join is strictly prohibited.

7. join ... on the back should not be used or, if need be used with the range or () enclosed.

8. not use select into the format. Select into a SQL Server-specific syntax, because Oracle and DB2 does not support.

9. Null value should be the empty string (zero-length string) considered different. Although Oracle, as the Null and empty string is the same, but DB2 and SQL Server has considered different.

Guess you like

Origin www.linuxidc.com/Linux/2019-11/161557.htm