Question about what the content should be for a database standards document

Question

Hi Experts,
I am working as development DBA in a J2EE project and have a task to create a database standards document. The document should be used as a reference by the developers when they submit requests for database changes - like adding or making changes to the database schemas (adding tables/modifying them etc.). I thought of what would be the right content for this type of standards document and I think that such a document should have the following as database standards:
1) Naming standards for the database objects.
This will include all database objects like tables, columns, primary keys, foreign keys, views, triggers, procedures etc.. For example a standard can be defined like: all primary keys should be named as PK_TABLENAME. All indexes should be named as <TABLE_NAME>_IDX01 etc.
2) Use of Oracle reserved words should be avoided in the schema object names.
3) The names should be descriptive so as to make their purpose self evident.
4) Wherever possible, tables should have primary keys.
5) Wherever possible columns should be defined NOT NULL -as it helps performance (Indexes on NULLABLE columns are not used by the optimizer).
6) When submitting request for a new table/tables, typical queries against these new tables should also be worked out and based on that indexes that will be needed for the new tables should be defined. In case this is not clear at the time of initial table creation, it should be clarified within 3 weeks (just a reasonable period to be mentioned here).
Is this fair enough content forthe standards document or does it miss some important aspects? Note that we do not have to cover in this document standards for database creation or RAC installation etc. It is a document of standards to be followed by developers as a reference when submitting database changes. I will be thankful for your review.
(Oracle version info: We are on Oracle 11.2.0.2 on Solaris 10.)
Thanks,
OraserN

Answer 1

rp0428 wrote:
>
5) Wherever possible columns should be defined NOT NULL -as it helps performance (Indexes on NULLABLE columns are not used by the optimizer).
>
That isn't true - post a link that supports that statement.
Heap indexes do not INDEX null values but indexes on NULLABLE columns are most certainly used by the optimizer for use cases where your query is looking for non-null values.
Columns should be defined NOT NULL when your business requirement is that the column should ALWAYS have a value. You can, of course, adopt some standard default value (e.g. 'U' for unknown) and make an otherwise NULLABLE column NOT NULL so that each row WILL be indexed. That may only be useful if you want to be able to search for rows that have that value and those rows are in the minority.Then I must be wrong....I will modify the standard as:
5) Whenever the business requirement is such that the column will allways end up having a value , then all such columns should be defined as NOT NULL. Also if a column can be defined to have a default value then this default value should also be specified.
Hope this is more proper then earlier and thanks a lot for the review!!
Edited by: orausern on May 13, 2013 9:53 AM