Appendix B. PL/SQL Standards 183
The function above takes the optional argument object_id. Do this to allow people to use the
same API call when they are doing double-click protection. That is, they have already gotten an
object_id and now they want to create the object with that object_id.
B.3. Coding Style
Some general style guidelines to follow for the purpose of consistency across applications.
1. Standard indentation is four spaces. Our PL/SQL code is not only viewable in the SQL files
but also through our SQL and PL/SQL browsers. This means that we should try to make it as
consistent as possible to all source code readers.
2. Lowercase everything, with the exception of %TYPE and %ROWTYPE.
B.4. Constraint Naming Standards
A constraint naming standard isimportant for one primaryreason: The SYS_*name Oracle assigns to
unnamed constraints is not very understandable. By correctly naming all constraints, we can quickly
associate a particular constraint with our data model. This gives us two real advantages:
• We can quickly identify and fix any errors
• We can reliably modify or drop constraints
Why do we need a naming convention? Oracle limits names, in general, to 30 characters, which is
hardly enough for a human-readable constraint name.
B.4.1. Abbreviations
We propose the following naming convention for all constraints, with the following abbreviations
taken from the Oracle documentation. Note that we shortened all of the constraint abbreviations to
two characters to save room.
Constraint type Abbreviation
references (foreign key) fk
unique un
primary key pk
check ck
not null nn
B.4.2. Format of Constraint Name
table name _ column_name _ constraint abbreviation
In reality, this won’t be possible because of the character limitation on names inside Oracle. When
the name is too long, we will follow these steps in order:
1. Abbreviate the table name with the table’s initials (for example, users -
u and users_contact
-
uc).
