Wasn't my question. Why do you need to label a table as a table? There is some merit in using type prefixes in VB because of its loose typing, but it makes no sense in a database context where the types of objects are quite distinct.
> -----Original Message----- > From: Adam Fortuno KOVICK [mailto:[EMAIL PROTECTED] > Sent: 01 August 2003 15:24 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: RE: standardized naming system ? > > > Jim, > > Great question! > > I use the ol'Reddick VBA naming conventions. > > tbl - table > idx - index > fld - field > > You can search them in google, but I'd like to know if MySQL has its > own established conventions too. > > Regards, > A$ > > ----- Original Message ----- > From: Jim Smith <[EMAIL PROTECTED]> > Date: Friday, August 1, 2003 10:03 am > Subject: RE: standardized naming system ? > > > > > > > Hello list, > > > > > > is there a common naming system for db objects ? > > > > Thousands. > > > > > Like: > > > > > > 1) Tables: mytable, tblmytable, tbl_mytable > > > > > > 2) Indices: idx_anindex > > > > > > 3) Columns: int_somenumber, date_lastupdate > > > > > > 4) id for the numerical primary key e.g. table customers.id > > > and then for referencing foreign keys > > > table addresses : addresses.customer_id or > > > addresses.customer_fk > > > > > > OK, I know I could name them the way I want but perhaps there is > > some> kind of common sense in this regard ? > > > > Common sense will do, but here is my take on it. > > > > There are three main objectives - portability, maintainability and > > consistency. > > > > General. > > Use long names. Don't abbreviate unnecessarily, but don't go to > > far that > > you have > > to rename all your tables if you move to a different DBMS. A > max > > of 30 > > chars should fit most DBMSs. > > > > Use lower case names, with words separated by underscores '_'. > > Some DBMSs > > are case > > sensitive, others aren't and some convert all names to upper > case > > ( this is > > an ANSI > > standard feature, I believe). If you use camel case ( > > studentClassScores),this could become > > STUDENTCLASSSCORES which isn't very readable, whereas > > STUDENT_CLASS_SCORESis much better. > > > > Don't use reserved words. Most DBMSs allow you to use reserved > > words with > > various degrees of effort, but why bother. Also try to avoid > > simple names > > which > > might be a reserved word in another DBMS. > > > > Tables. > > Give tables a clear simple name which represents the content. > If > > it holds > > student records, call > > it "students"; course details, "courses" etc. > > Also assign each table a unique 2-4 letter prefix for use in > > naming objects > > which belong to that table. > > > > Columns > > Again say what it is. I use the prefix referred to above in all > > columnnames, but some people think that > > is a waste of name space. > > e.g std_id, std_surname, std_forename, student_birthdate, > crs_name, > > crs_tutor_id, etc > > > > Constraints > > Use the prefix > > Primary Key std_pk > > Foreign Keys std_fk_col ( i.e. > <source_prefix>_FK_<target_prefix> > > Unique Keys std_uk_nn where nn is a sequence number. Some > > people like > > std_uk_<column_name>, but > > if you have a composite > > key, that doesn't work. > > > > Indexes > > Where an index is used to enforce (or instead of) a unique or > > primary key > > constraint, same name as the constraint. > > Primary Key index std_pk > > Unique Index std_uk_nn > > Non-unique index std_nu_nn > > > > If indexes share the same namespace as constraints, stick an i_ > > on the > > front of the index name. > > > > > > > > -- > > MySQL General Mailing List > > For list archives: http://lists.mysql.com/mysql > > To unsubscribe: > > http://lists.mysql.com/[EMAIL PROTECTED] > > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
