oracle database design specification

one

1. First build a logical model, that is, an ER diagram, and then map it to a physical model.

2. Regarding the paradigm, the standardized data model is generally not the final result, but it is always the best starting point for modeling.

Keys, full keys, nothing but keys.

3. Regarding the choice of data type.

Because oracle uses a very flexible approach to the physical storage of data types, there is no advantage in using highly restrictive data types or precision from storage and performance considerations.

 

two

When choosing a data type, pay attention to the following:

1. In most cases, no matter how you limit the data type, Oracle will use a large range of high-precision floating-point methods for storage, for numbers and dates.

Even if you specify a precision for a number, the precision is more for constraining data or defining documents than for optimizing performance.

There are exceptions, that is, precision can reduce the length of the data, which will help improve performance.

 

2. Fixed-length strings will occupy a fixed-length storage space. Using a fixed length can reduce fragmentation, but may result in a larger average row size, which increases the overhead of full table scans.

Therefore, unless you are very sure that the length of the string is certain, such as the MAC address, you should choose the variable-length string type.

 

3 varchar will be replaced by varchar2 after 11g, and the two are the same at this stage.

 

4. For large files, the lob type is recommended. Blob binary, Clob text, bfile external storage.

 

Three about human construction:

Artificial keys usually give better performance than natural keys.

It usually consists of a numeric type.

Compared with natural keys, it will reduce the overhead of table joins and the overhead of index queries.

 

The logical model should not be mapped to the physical model one-to-one. The logic mainly considers the realization of the function, and the physics mainly considers the performance and storage method, which can greatly save the time for subsequent tuning. ! !

 

Four on the choice of table type

talk later

 

5. About null values

Do not store nulls in ordinary indexes, and nulls will not go through the index, only full table scan.

 Composite indexes and bitmap indexes can store null.

Using null can reduce the average length of rows, thereby improving the performance of full table scans to a certain extent.

Change the query null to query a default value, just to walk the index. ! !

The storage of null values ​​requires one byte of storage space.

 

order of six columns

Accessing the later columns requires a small amount of additional CPU resources than the earlier columns. Based on this, bringing frequently accessed columns to the front will bring a small performance improvement.

 

Seven Denormalization

1. Copy the column value

Mainly to avoid using table joins for queries.

 

 

Three physical aspects

physical storage solution

1. When inserting new records into the table, Oracle needs to scan the linked list of free data blocks. ASSM can automatically complete the free data fast linked list to avoid linked list contention. For tables with frequent insert transactions.

 

2. Avoid row migration by properly setting pctfree. Data go, leave pointers.

 

3. When a transaction changes a block, a transaction slot is obtained, and if the transaction slot cannot automatically increase the allocation, the transaction will wait.

 

4. Data compression basically means that it can improve the performance of full table scans. My understanding is that range scans can also improve performance. The compression rate of strings is greater than that of numeric types, and the compression benefit of data on disk is greater than that of data in memory.

 

5 about lob

Generally store more than 4000 bytes of data, otherwise use varchar2 to store. Under normal circumstances, Lob data is not stored in the same data block as other columns recorded in the same row, and is stored inline only when the number of lob objects is less than 4000.

Control method: enable/disable storage in row.

If the LOB field is a field that needs to be accessed frequently, it is recommended to use inline storage. Because accessing externally stored lobs requires additional IO.

 

Please set the db_securefile parameter to set the default storage method of the new lob column to secure file.

 

6 About partitions

 

Partitions are mainly at 2 points, partitions are eliminated, which is convenient for managing historical partition data without affecting the current partition.

 

Regarding the design principles, the above content is reproduced: http://blog.csdn.net/familyrun/article/details/47037393

 

Regarding the specification of details:

  1. If indexing is required during development, a written change request needs to be submitted, stating the definition of the desired index (name, field list, order, index type) and the rationale for establishing it. The database administrator maintains the index uniformly and changes submitted requests.
  2. The initial data of each table in the database (including each code table and configuration table) needs to be submitted to the database administrator.
  3. Triggers must not be used.
  4. Changes (Insert/Delete/Update) involving database multi-table data must be controlled using database transactions, and must have complete transaction start and commit/rollback mechanisms. cannot use scoped transactions
  5. Try to avoid the use of the Union operation. If you need to use it, please consult the database administrator about the impact of using the Union operation.
  6. For SQL statements and stored procedures, try to use the code beautifier of PL/SQL Developer to beautify them.
  7. The size of keywords belonging to ORACLE, table names, column names, etc. are lowercase.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325652105&siteId=291194637