Naming conventions

 Stored Procedures

Stored procedure names should conform to the following convention:

AppName_ActionName< ?xml:namespace prefix ="" o ns ="" "urn:schemas-microsoft-com:office:office" />

e.g. HES_GetOfferDetails

 

Property

Description

AppName

Name of the application/system that uses the stored procedure. E.g. “AM” (AdMaker),” HES”,” CPT”, etc

In some cases it could be a variant of the application, e.g. “VHES_Admin”

ActionName

Name of the action using Pascal notation. This should start with a verb (e.g. Get, Update, Delete…).

 E.g: GetOperators, AuthenticateUser, InsertOffer, DeleteRegion, Upd ateDPN

 


Additional Information Within Stored Procedures

Each stored procedure should include supplementary information that covers:

·         Author and creation date

·         Short description of what the stored procedure does

·         Description of input parameters (when not too obvious). Default values can be specified in the format: “[12]”.

·         Where it is used (platform, section, etc)

If any modifications are made to an existing stored procedure then the following additional information should be provided each time:

·         Author of the modifications and the date they were made

·         Short description of the changes made

 

Example header (with modifications):

/************************************************************

 AN – < ?xml:namespace prefix ="" st1 ns ="" "urn:schemas-microsoft-com:office:smarttags" />31/10/00

 Description: Returns all destinations for a particular group.

 Input: @GroupId: Group Id (from table DestinationGroups) [1]

************************************************************

History:

 

AN – 02/01/01

Modification to the number of fields returned by this stored procedure

 

AN – 04/08/03

Added FieldId field in the select statement

************************************************************/

 

Tables

a)     Table names

Use a descriptive name use Pascal notation. Tables will normally be one or more nouns that should be expressed in plural. E.g. AccommodationTypes, Offers.

When creating a table that link two other tables use the form <table1>To<table2>. E.g. MasterToDetail.

 

b)     Fields

When naming fields within tables, the following method should be used when naming primary and foreign keys:

In the table with the primary key: PrimaryTable (TableNameID, FieldName1, FieldName2…)

In the table with the foreign key: FKTable (PrimaryTableID, FieldName1, FieldName2…)

Use the singular form for the primary key field; i.e. use OfferID instead of OffersID.

For example if the table Users had a primary key called UserID and this was used as a foreign key in the table Addresses you should use:

 

Table name

Fields

Users

UserID, Password, CreationDate, LastLogIn

Addresses

AddressID, UserID, HouseNumber, RoadName, Town, Postcode

 

 

c)      Indexes and foreign keys

With respect to Indexes and Foreign keys the following conventions should be adopted:

Index                     -               IX_<TableName>_<ColumnName1>_<ColumnName2>…

Foreign Key         -               FK_<FKTable>_<PrimaryTable>

Idx and FK are prefixes indicating an index and a foreign key respectively, TableName is the name of the table concerned and ColumnName is the name of a column that is included.

PrimaryTable is the table that contains the primary key and FKTable is the table that contains the foreign key. Use abbreviations when the table names are too long. 

Examples of valid foreign keys and indexes for this example:

-          IX_HolidayOffers_Price_Nights: index on fields Price and Nights from HolidayOffers table.

-          FK_HolsOffersToOfferTypes_OfferTypes: Foreign key from HolsOffersTo OfferTypes to OfferTypes.

Views

Use a descriptive name in Pascal notation.

 


3         Annex A – Pascal notation

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters.

For example: BackColour, TradingName, TelephoneSet.