IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Re: Any preferred naming conventions?
I've seen a couple used before:

tTableName.fFieldName
vViewName.fFieldName

t, v, and f are literally there. So:

tVendor.fVendorID

Another one which took me a while to understand why they did it like this:

table_name.uniqueid_field1
table_name.uniqueid_field2

along with:

table_2_name.uniqueid2_field1

So you could do something like:

SELECT uniqueid_field2, uniqueid2_field1
FROM table_name, table_2_name
WHERE uniqueid_field1 = uniqueid2_field1

Example:

vendor.v_vendorid
vendor.v_name

product.p_productid
product.p_vendorid

SELECT p_productid, v_name
FROM vendor, product
WHERE p_vendorid = v_vendorid

No need to worry about fieldname clashes. It's a bit tedious, but saves you from having to alias tables in your queries, and having to worry about that whole bit.
-YendorMike

Real programmers use "vi a.out".
Expand Edited by Yendor Feb. 19, 2002, 03:14:15 PM EST
New Extension of this idea.
On the database I'm working with now, there was an effort to make field names globally unique, though we haven't completely succeeded. Generally, important tables give one letter prefixes to their field names (table contacts has a field c_firstname, for instance), while other tables get longer abbreviations.

The extension we're using is that if the table has a unique ID - i.e. an autoincrement column - then it gets an "id" field. So, the contacts table has a c_id field, etc.

Wade.

"All around me are nothing but fakes
Come with me on the biggest fake of all!"

New Foreign keys
>> The extension we're using is that if the table has a unique ID - i.e. an autoincrement column - then it gets an "id" field. So, the contacts table has a c_id field, etc. <<

One convention I have seen that I liked is to use suffix "_ref" for foreign keys (and the regular "_id" for primary keys). In your example, a reference to the "c" table (via c_id) would be "c_ref". Or say "vendor_ID" and "vendor_Ref". Another variation is "_fk", but that looks like an insult if you read it fast.



________________
oop.ismad.com
     Any preferred naming conventions? - (drewk) - (19)
         Re: Any preferred naming conventions? - (admin) - (10)
             That's about what I'm trying to do - (drewk)
             Busting Abstraction? - (tablizer) - (8)
                 Many times that abstraction is put into a stored procedure - (admin) - (7)
                     But you would still have to change "ta-x" to "sp-x" -NT - (tablizer) - (6)
                         Uh, no. - (admin) - (5)
                             Field management? - (tablizer) - (4)
                                 Choke point - (ChrisR) - (3)
                                     you looz some flexibility that way IMO - (tablizer) - (2)
                                         Huh? - (Yendor) - (1)
                                             I don't believe you - (tablizer)
         Re: Any preferred naming conventions? - (Yendor) - (2)
             Extension of this idea. - (static) - (1)
                 Foreign keys - (tablizer)
         Chin up, Drew, that's not so big a problem! - (CRConrad) - (2)
             "I work for a living" - (drewk) - (1)
                 The meat between my ears isn't completely occified... yet. -NT - (CRConrad)
         A good idea not to follow - (nking)
         Very simple (minded?) convention - (wharris2)

When The Wall fell, I had a basement full of homebrew and a freezer full of venison here in The Land of the Free. All quite legal, unless I committed capitalism, in which case it becomes felonious.
70 ms