c
 


 
 

  Y

1. Normally, use only alphanumeric characters for table names (i.e. EmployeeAddress).
2. Table names should not normally start with a digit.
3. It is recommended that table names are restricted to 25 characters or less.Y
a
 Y

1. Normally, use only alphanumeric characters for column names (i.e. EmployeeName).
2. Column names should not normally start with a digit.
3. It is recommended that you restrict column names to 25 characters or less.
4. No SQL language reserved words should be used as column names. Y
c

Y

1. Select data types appropriate to the target RDBMS. Designs should be as RDBMS
agnostic as possible: for example, minimize use of sets and abstract data types, unless
these are key to the design. It is accepted that that there will inevitably be some RDBMS
specific data typing. Y
a
Y

1. Codes should always aim to be clear, concise, consistent, and commented.Y


Y

1. Database users should only be granted sufficient privileges to enable them to perform the
tasks that they need to.
2. When connecting from web applications, where possible always connect to the database
as the same user. This minimizes the chances of leaving a security hole against a particular
user, and enables connection pooling techniques to be more readily taken advantage of to
improve performance.
3. Plain text passwords should never be displayed in client side code.

c
 Y
1. Date/Times within the database should normally be stored as SQL default format. Any
conversion required should be done at the client end of the application.
2. When converting date/times from internal to string format, the format: "«.YYYY-MM-DD
HH24:MI:SS««.." should be used if there is a requirement to sort resultant string values
'chronologically'. Y
-  

Y

1. All scripts, modules, functions, procedures should contain a header and footer including a
description of the main purpose of them, the date last updated, the author (last modifier),
and the version.
2. All procedures and functions should contain a header and footer including a description of
purpose, parameters, exceptions thrown, and possible return codes.
   a


Y
1. Connections should always be closed after use.
2. All database resources associated with a used connection should be explicitly released
before the connection is closed. Resources MUST be released correctly when error or
exception conditions occur.
3. Connections should be cached in DEFAULT mode.Y
 


Y

1. Every table should have a comment/description of its purpose included in the (optional
database design document, and schema creation script (to ensure this is available in the
database data dictionary).
2. Every column of every table should also have a column comment in the optional database
design document (where available/completed) explaining its purpose, default value, etc.Y
 Y

1- On operational databases, assume that full backups will be made weekly, and
incremental backups made daily. Any specific backup/recovery requirements should be
discussed with Hosting Company as needed.Y

Y

3. Always test the application in unit testing, integrated testing and system testing.
4. Test the application in different platform. For example, test a web in both Netscape and
Explorer before release.Y
Y