I've been interested in database naming conventions for a long time. I
remember long ago some book author suggested prefixing every field
with the table name. The reason was to avoid conflicts between table
names and fields ( I think ... anyone have an example? ).

Anyway, I think I like these naming conventions best:
http://search.cpan.org/dist/Rose-DB-..._CONVENTION S

but there is a good discussion of the 't_' ... 'f_' technique here:
http://groups.google.com/group/web2p...8fc8fb48015467

any other links to naming conventions are welcome.

On Fri, 18 Mar 2011 09:31:24 -0700 (PDT), metaperl <schemelab (AT) gmail (DOT) com> wrote:

Have you considered the Leszynski naming convention (LNC)?
- http://en.wikipedia.org/wiki/Leszyns...ing_convention
I disagree with end of the opening statement (...it is not widely used elsewhere) - I have seen
[selected parts of] it in use for Oracle databases at one of my employers, also something similar to
LNC elsewhere.

Personally, I have sometimes used tbl_ for table prefixes, fnc_ for functions, ix_ for indexes and
so on. On other ocassions I have used the database/project code initials as prefixes for schemas.

Many database developers and DBAs have their own variations, so the answer to your question is
likely to be subjective. However, whatever you chose I recommend sticking with it since it is likely
to make [your] life easier when examing sql scripts long after they've been developed, especially if
your memory is as bad as mine.

HTH

metaperl <schemelab (AT) gmail (DOT) com> writes:

That's a good set, except I'm firmly in the “name of the relation is the
name of the entity it represents” camp – not to mention the needless
pain of irregular plurals in English and other languages – and hence
table names are singular only (which I see they acknowledge and support
as an option).

With that change, I'd be happy to advocate such a set of conventions.

Others:

<URL:http://www.interaktonline.com/Support/Articles/Details/Design+Your+Database-Database+Naming+Convention.html?id_art=24&id_asc=2 21>
<URL:http://justinsomnia.org/2003/04/essential-database-naming-conventions-and-style/>
<URL:http://stackoverflow.com/questions/338156/table-naming-dilemma-singular-vs-plural-names>

--
\ “To me, boxing is like a ballet, except there's no music, no |
`\ choreography, and the dancers hit each other.” —Jack Handey |
_o__) |
Ben Finney

On Mar 18, 11:31*am, metaperl <scheme... (AT) gmail (DOT) com> wrote:

I havea whole book on this kind of thing (SQL PROGRAMMING STYLE)
based on the research we did at AIRMICS, the research done in
typography and ISO-11179 rules.

That advice is wrong. Each data element should have one and only one
name that does not change from table to table, and ideally it stays
constant anywhere. You name a thing for what it is by its nature,
NEVER for
1) Where is is used (no table or view names)
2) How it is used (no PK- or FK- or VW-)
3) How it stored (no data types or indexes, or whatever)

I would recommend to have a look at Joe's book and use it as a basis
for your own convention.

If you could manage to have one name for a data element in all tiers
of your application, you could save a lot of time and headache. For
example the data element is product_code, so is the column name. If
you read it into a variable of your front end it is also named
product_code. Then you have a text box for input
(product_code_textbox) and a search button
(product_code_search_button). In consequence a vague "code" as a data
element name would not do it, neither would spaces in the name work.

brgds

Philipp Post