From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: Naming conventions
Organization: 
Date: Wed, 29 Jul 1992 22:05:29 GMT

In article <1992Jul27.145402.11313@schaefer.math.wisc.edu>,
horn@schaefer.math.wisc.edu (Jeffrey Horn) writes:
> How do YOU name database objects and ingres application objects.  I am
> interested in naming conventions for:
>
>     Databases
>     Tables
>     Forms
>     Frames
>     4gl procedures
>     SQL Procedures
>     Rules
>     Database Events

Here's a summary of some of our naming conventions.

Databases

For system XXX we usually set up three database with names:

    XXXprod	Production database. Minimal frontend objects,  usually
		just reports. (We don't use QBF for production work
		so no forms or joindefs are stored in the production
		database.)

    XXXtest	Periodic snapshot of the production database
		for testing new applications, different tables designs,
		etc.

    XXXdb	Development database, usually with a small subset of real
		data.  ABF work takes place here.

Database Areas

For database areas we use VMS rooted logicals:

	$ define/translation=concealed area_name device:[dir.]

We define a complete set of logicals for each and every database, even
if two database physically share a disk.   We create separate areas for
data, checkpoints, journals, and dump files.  This gives us complete
flexibility to relocate any part of a single database to other disks
with VMS BACKUP (to move the files) and logical name redefinition (to
tell INGRES where to find the relocated files) without interfering with
any other database.  The database locations defined in ACCESSDB remain
unchanged.

Our conventions for these area logical names are:

	default database area	DB_dbname
	extended areas		DB_dbname_1, DB_dbname_2, ...
	checkpoint area		CKP_dbname
	journal area		JNL_dbname
	dump area		DMP_dbname

Does anyone know how to do this Unix?  Is it necessary, in view of soft
links?  In VMS, our scheme is _very_ useful in making all databases
completely independent of one another.  It's very easy to move all or
part of a database when we have to shuffle things around because a disk
fills up or breaks.

Tables

Our databases (academic administration) tend to have subdomains (e.g.,
Admissions, Dean of Students, Alumni).   Some tables are common to all
subdomains (e.g., basic biographic information, code constraint tables)
and some are specific to subdomains (e.g., application data, registered
courses,  alumni donations).  We use a short prefix for each table to
identify it as common (global in our terminology) or subdomain specific.
Our table codes are

	GL_	Global (common)
	AC_	Academic Servics
	AD_	Admissions
	DV_	Alumni/Development
	PO_	Placement Office
	RG_	Dean of Students/Registrar

You get the idea.  Since version 6 we've tended toward longer table
names, with underscores to separate words.  Our table names are always
singular, so that the name defines what one row from the table is, not
the whole collection.  For example, the table that holds persons is
"gl_person", not "gl_persons".

For secondary indexes, the convention is "x_tname_cname", where "tname"
is the name of the table and "cname" is the name of the first column in
the index.

For views, we use exactly the same conventions as for base tables.  SQL
is supposed to treat tables and views the same, so we name them the
same.

The convention makes it easy to identify what a table is for and which
system it belongs to.  

Forms

We use the same subdomain prefixes as for our tables, and add a suffix
to every form name, "_f".   The reason for the suffix is that we write a
fair number of frames in embedded SQL/C (though as 4GL gets better that
trend is changing), and we need two distinct names, one for the C
procedure and one for the form (otherwise you get a linker name conflict
between the procedure and the compiled form).

	c procedure: xx_frame_name
	form name:   xx_form_name_f

This convention is not so binding for 4GL frames, where the framename
and formname can be identical.  The convention makes it easy to find the
form for a given frame, and, conversely to figure out what source code
goes with a given form.

Within forms, we have some conventions for the names of table fields and
simple fields.  All table field names look like "person_tf", where the
name indicates what a row in the table field represents, and the "_tf"
suffix makes it easy to see what the object is in source code.  Simple
fields usually have the same name as the column in the database that
they correspond to.  We also have simple fields like "person_tfn", which
displays to the user how many rows there are in the corresponding table
field.

4GL frames, 4GL procedures, 3GL procedures.

We use a similar subdomain prefix naming convention for all our
procedures (all flavors).  In addition to the administrative subdomains
listed above we introduce additional prefixes as needed to identify
significant application subcomponents or general utility libraries.

	DV_	Alumni/Development System
	GF_	Gift Entry Subcomponent
	PO_	Placement System
	PB_	Student Interview Bidding Subcomponent
	TX_	Transaction and Error Handling Utility Library
	FRS_	FRS Utility Library
	STR_	String Utility Library

Local procdures (4GL local procedures and C static functions) are given
a prefix specific to the module they are in, but this is not as
critical.

Rules and SQL Procedures

We don't actually have a lot of database procedures or rules, but I have
thought about this and decided on this convention: "tname_oper_rule" for
the rule, and "tname_oper_proc" for the procedure that the rule invokes. 
"tname" is the name of the table; "oper" is the update operation
(insert, update, or delete); and "rule" is fixed text that indicates the
type of the database object.  This makes it really easy to do things in
the SQL terminal monitor such as "help rule tname*", so you can see all
of the rules that are defined on a table.

--Mark Jaeger				internet: cs_mj@gsbvax.uchicago.edu
--Paul Ford				internet: cs_paul@gsbvax.uchicago.edu
Graduate School of Business		yellnet:  (312) 702-7411
University of Chicago			faxnet:   (312) 702-0233
Disclaimer: Our opinions are our own and not those of my employer.

Newsgroups: comp.databases.ingres