Back-End Standard

Naming Conventions and Standards

• Database Object Name (i.e. Table, Sequence, View, Index, Trigger, Package, Procedure, Function, Materialized View, Job, Type, Directory, Constraints, Synonyms and Tablespace ) should be meaningful. Example : Table Name "HRS_EMPLOYEE_PERSONNEL"
• Column Name should be clearly defined and meaningful. Example : Employee_ID
• Database Object name and Column name should not contain the Number and Special characters except "_" character
• Constraints name should be clearly defined and must be used the prefix and suffix when creating the constraints

Constraints Name
Abbreviation	Description	Example
fk	References (Foreign Key)	hr_emp_empid_fk
uk	Unique Key	hr_emp_empid_uk
pk	Primary Key	hr_emp_empid_pk
ck	Check	hr_emp_empid_ck
nn	Not Null	hr_emp_empid_nn

• Use the following prefix in Identifier/Variable naming conventions (Local Variable, Global Variable, Parameter Variable, Constant Variable)

Abbreviation	Description	Example	Comment
k	Constant	k_mailhost	Generic constant
g	Variable	g_loop_count	Global (package-level) variable
v	Variable	v_loop_count	Local variable
p	Variable	p_loop_count	Parameter variable

• Use the following prefix for scalar types that have aggregate data types.

Abbreviation	Description	Example
c	Cursor	c_employees
cp	Cursor parameter	cp_employee_id
r	Record	r_employee

• The suffix is used to qualify the identifier further by documenting its usage. For example, the suffix denotes the type of parameter, whether IN, OUT, or IN OUT, or to show that a variable or parameter is also a table.

Type	Description	Example
	Input-only parameter	p_num_items
out	Output-only parameter	p_sum_out
inout	Both input and output	p_sum_inout

Product Naming Conventions and Standards

• Use the following prefix in Table, Sequence, Package, Procedure, Function, Trigger, Materialized View , View, Index should be meaning full and start from Module name

Prefix	Module Name
SET	Settings
SEC	Security
HRS	Human Resource System
PAY	Payroll
TOM	Time Office Management
OSP	Office Support Portal
ESS	Employee Self Service / Web Portal General Settings
COM	Communication System
MRR	Meeting Room Reservation
HRS_EREC	E-Recruitment
ARC	Correspondence System
INV	Inventory Module
FIN	Finance Module
PUR	Purchase Module
CON	Contract Module
DFS	Date Factory System

• Example Naming Standard of Database Objects for Table Specific

Objects	Module Prefix	Object Name	Object Type Suffix	Example
Table	SET_	TABLE_NAME		SET_LOCATION
View	SET_	TABLE_NAME	_VW	SET_LOCATION_LOC_ID_SEQ
Sequence	SET_	TABLE_NAME_COLUMN_NAME	_SEQ	SET_LOCATION_LOC_ID_SEQ
Package	SET_	TABLE_NAME	_PKG	SET_LOCATION_PKG
Procedure	SET_	TABLE_NAME	_PRO	SET_LOCATION_ PRO
Function	GET_	TABLE_NAME	ColumnName	GET_LOCATION_NAME
Trigger	SET_	TABLE_NAME	_TRG	SET_LOCATION_ TRG <_BU> (Before Update) <_BI> (Before Insert) <_AU> (After Update) <_AI> (After Insert)
Materialized View	SET_	TABLE_NAME_COLUMN_NAME	_MV	SET_LOCATION_ MV
Index	SET_	TABLE_NAME	_IDX	SET_LOCATION_LOC_ID_IDX
Constraints	SET_	TABLE_NAME_ ColumnName	_IDX	SET_LOCATION_LOC_ID_IDX
Constraints	SET_	TABLE_NAME_ ColumnName	_PK_UK_CK_NN_FK	SET_LOCATION_LOC_ID_PK, SET_LOCATION_LOC_ID_UK,SET_LOCATION_LOC_ID_CK,SET_LOCATION_LOC_ID_NN,SET_LOCATION_LOC_ID_FK

• Example Naming Standard of Database Objects for General use

Objects	Suffix	Abbreviation	Example
Package	_PKG	ModuleName / MeaningFullName ModuleName_Reports_PKG (For Reports) ModuleName_PKG (For general user for whole module)	HRS_LEAVE_PKG INV_REPORTS_PKG DFS_COMMON_PKG
Procedure	_PRO	ModuleName / MeaningFullName / Table Name	INV_ITEM_BALANCE_PRO
Function	GET_	ModuleName / MeaningFullName	GET_HIJRI_NEXT_MONTH
Trigger	TRG_	ModuleName / MeaningFullName,<_BU> (Before Update) <_BI> (Before Insert) <_BD> (Before Delete) <_BF> (Before insert, update, delete) <_AU> (After Update) <_AI> (After Insert) <_AD> (After Delete) <_AF> (After insert, update, delete) <_IU> (Instead of Update) <_II> (Instead of Insert)<_ID> (Instead of Delete) <_IN> (Instead of insert, update, delete)	TRG_LOCATION TRG_LOCATION_BF TRG_LOCATION_BI TRG_LOCATION_AU TRG_LOCATION_AI
Materialized View		TableName
Type	TYP_	MeaningFullName	TYP_GROSS_PAY

Good Programming practices

There are several guidelines for SQL best practices, and some that apply directly to Oracle SQL. In general, Oracle SQL best practices include these techniques

• Rewrite complex subqueries with temporary tables - Oracle create the global temporary table (GTT) and the SQL WITH operator to help divide-and-conquer complex SQL sub-queries (especially those with WHERE clause subqueries, SELECT clause scalar subqueries and FROM clause in-line views). Tuning SQL with temporary tables (and materializations in the WITH clause) can result in amazing performance improvements.

• Use minus instead of EXISTS subqueries - Some say that using the MINUS operator instead of NOT IN and NOT Exists will result in a faster execution plan.

• Use SQL analytic functions - The Oracle analytic functions can do multiple aggregations (e.g. rollup by cube) with a single pass through the tables, making them very fast for reporting SQL.

• Re-write NOT EXISTS and NOT EXISTS subqueries as outer joins - In many cases of NOT queries (but ONLY where a column is defined as NULL), you can re-write the uncorrelated subqueries into outer joins with IS NULL tests. Note that this is a non-correlated sub-query, but it could be re-written as an outer join.

• Remove unnecessary large-table full-table scans - Unnecessary full-table scans cause a huge amount of unnecessary I/O and can drag-down an entire database and it's a SQL best practice to identify unnecessary full scans and remove them by adding indexes.

• Cache small-table full-table scans - Caching is a SQL best practice in cases where a dedicated data buffer is available for caching table rows.

• Verify optimal index usage - This is one of the most important SQL best practices where you examine your SQL and verify that your SQL is using the most selective.

• Materialize your aggregations and summaries for static tables - One SQL best practice features of the Oracle 10g SQLAccess advisor is recommendations for new indexes and suggestions for materialized views.

• The Basic format of Block Structure is as follows:

DECLARE (Definition of any variable or objects that are used within the declared block)

BEGIN (Statement that make up the block)

EXCEPTION (All exception handlers)

END; (End of block marker)