Database

Standard
Tables
Types
Indexes

Constraints
Views
Sequences
Packages
File extensions
Schemas
Utility schema
Synonyms
Packages

Views

Constraints
Indexes
Triggers
Database links

Modularity

1 June 2014

Detail
Naming Convention
Abbreviation domains may be defined for use in column names (_DT for
Normally plural and meaningful
date, say, and application-specific abbreviations)
ty_XXX_, then: rec/obj/tab
ty_ prefix, suffix by object type: Flat/complex/table (all array types)
TABLE_NAME_Un
nth unique index
TABLE_NAME_Nn
nth non-unique index
TABLE_NAME_PK
Primary key
ALIAS1_ALIAS2_FK
Foreign key (if multiple, add distinguishing text as a third token)
TABLE_NAME_UK
Unique key
XXX_CHK
Check
XXX_V
TABLE_NAME_SEQ
for surrogate keys, otherwise meaningful name with _SEQ suffix
Entry-point method for use typically by client applications;
Meaningful names; no need for AIP_xxx
may represent a transaction
_PKG; nor for _PRC, _FUN or
Shareable helper method, body-only unless used by
similar for methods
SSP_xxx
multiple packages; no transactionality
.pks, .pkb; .sql
Package spec, body; other files executed from SQL*Plus
Structure
Use schemas to logically subdivide application objects; code and data are often in separate schemas
Each system will have a schema for shared generic objects, including error logging tables and packages, and
wrapper packages for monitoring tools such as DBMS_Profiler
Public synonyms
Use for common objects in the utility schema
Private synonyms
Use for objects other than common objects
Avoid stand-alone procedures and functions, putting related methods into packages
Use packages with modularity in mind, thinking in terms of transactional APIs and shareable methods
Do not use PL/SQL to convert subqueries into arrays, as leads to overcomplexity and performance problems
One-table views can be freely Access control, as in Oracle eBusiness multi-org views
Thin views
joined, and may be used for
Edition-based redefinition
the following purposes
Layers to hide table and column names from calling queries
Use where a complete query may be repeated, varying just
Multi-table views should
Where clause and Select list; or, from client calls
rarely be joined, only when
Thick views
the underlying query is an
Avoid kitchen-sink views for sharing of joins as these lead
exact match for the use-case
to overcomplex underlying queries
Use key and check constraints wherever possible: As well as protecting data integrity, they inform the CBO
Foreign keys should generally have associated indexes
Triggers tend to cause maintenance and performance problems, and are rarely necessary
Avoid joining across database links: Where necessary consider interfacing the data into local staging tables
Use shareable objects, including tables, views and packages where possible, but
Avoid over-sharing, where extensive inter-dependence between modules can be introduced; this is
especially a problem when attempts are made to turn subqueries into modules avoid this
See Modularity in SQL: Patterns, Anti-Patterns and the Kitchen Sink for worked examples involving
modularity in SQL

Brendans 2-Page Oracle Programming Standards

Page 1

SQL
Standard

Syntax
Hints
Modularity
Query structure
PL/SQL functions

Detail
Formatting as PL/SQL
Structure
ANSI syntax is preferred, as its both clearer and more powerful
Good for troubleshooting in dev, but production use should be exceptional
Some hints can provide information to CBO, for example CARDINALITY in case of unavoidable array usage
Use subquery factors freely to improve readability (often clearer than inline views)
Do not split SQL statements into multiple statements just for reason of length
Design queries, using subquery factors, analytic functions and other advanced techniques, for
performance and readability
Avoid calling PL/SQL functions Read consistency is lost
from SQL that contain SQL
Performance problems from re-execution of SQL per record
because
Over-complexity (and performance) problems with kitchen-sink functions

PL/SQL
Standard
Constants
Parameters
Variables
Type variable
suffixes

Case
Alignment
Indentation
Lineage
Table aliases
Tabs and spaces

Exception handling
Scoping
Bind variables
Comments
Magic values
Concision
Maximise SQL
Bulk processing
Dynamic SQL
Modularity

1 June 2014

Detail
Naming Convention
c_name
p_name
Input
x_name
Output and Input/Output
g_name
Global variables
l_name
Local variables
name_csr
Cursors
name_rec/name_obj/name_tab Suffix for object type: Flat/complex/table (all array types)
Formatting
Key words
Upper case
Packages/Methods
Mixed case (capitalize acronyms, initcap words, etc.)
Other
Lower case
Use to aid readability
Left-align lists; optionally, align the = in a list of join or where conditions
3 spaces for loops, blocks etc. Avoid excessive indentation
One line per item in a list, usually, such as table or column lists
Use full, descriptive aliases for subquery factors and short but meaningful aliases in select table list
Replace tabs with spaces to avoid alignment problems in different IDEs
Structure
Expected errors
Trap at the level the error arises
Trap at top level to avoid duplication; SSP_ methods do not trap these
Unexpected errors (OTHER)
Never use: WHEN OTHERS THEN NULL
Keep scope as narrow as possible
Package methods never in spec if not used outside the package
PL/SQL variables and parameters are automatically used as bind variables in static SQL
Ensure dynamic SQL also uses bind variables in general
Use package and method headers, with version histories and descriptions
Avoid excessive commenting in code bodies; prefer self-documenting code
Avoid hard-coded literals and numbers: Use named constants and/or store values on the database
Dont default variables to null
Avoid redundant code, eg
No IF Boolean = TRUE THEN
Learn SQL properly, including analytic functions, in order to use its full power
Any logical flat record set should generally be obtained via one query
Avoid slow row-by-row processing via cursor loops in favour of set-based SQL
Use where applicable to improve performance, but pure SQL is generally better; use arrays sparingly
Use only where important benefits, such as in Hides dependencies from database
modularity, arise, owing to the drawbacks
Syntax errors not picked up at compile time
Use local methods freely to centralise code thats repeated within the package or method

Brendans 2-Page Oracle Programming Standards

Page 2