Re: naming conventions for constraints

From: Hans Forbrich <forbrich_at_telusplanet.net>
Date: Wed, 30 Apr 2003 14:23:08 GMT
Message-ID: <3EAFDB2E.7E840755@telusplanet.net>

Some thoughts:

• standards should be easy to remember and implement otherwise they get bypassed
• standards should be flexible enough to be upgraded as necessary
• standards need to get approval from everyone using them, which can be a tedious process
• new standards should leverage existing standards
• very few, if any, other than DBA will see most of these, therefore the naming should be designed to make things easier for you

From the leverage one, if you have a table/view or other naming convention, you are 1/2 way or more to your goal.

From the last, I've always tended to look at my objects using DBA_OBJECTS. I've always found it useful to start the constraint name with the supported object (table) name to make lists easier to generate. Therefore I use suffix notation. My convention has been

'table name or table abbrev' || "_"

    < || col name or abbrev || "_" >
    < || segment || "_" >
    < || count >

    || type

where

    segment an int useful in partitioning     count is the increment

        (some like to use FK2, I prefer 2FK - always known spot)     type is a 2 char constraint type

My other standards include
- a table/view naming

• a column naming convention
• for each table name have an abbreviation
• for each column name have an abbreviation
• all objects except constraints end in a 1 char type
• never include hostname in any object definition (limits migration)

Some of my standards are actually very old and some might be downright stupid , but they work - for me.

Bottom line - it really doesn't matter what you use as long as it is consistent, easy to learn/remember and not stagnant. Whatever you decide, ***document the reasons*** because someone will come along and challenge it. Then if the challenge is strong enough, you can document the reason for change. <g> Received on Wed Apr 30 2003 - 09:23:08 CDT