Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Final say: Field Naming Convention
Message
De
24/01/2002 08:33:11
 
 
À
23/01/2002 18:19:58
Information générale
Forum:
Microsoft SQL Server
Catégorie:
Conception bases de données
Divers
Thread ID:
00608378
Message ID:
00609622
Vues:
18
>1) Column names should be fully qualified whenever possible for future scalability and performance reasons. Yes, it's tedious to always add the server.tablename prefix, but if you ever have to connect to another database and/or server, it will be INSTANTLY beneficial. Plus it's self-documenting. This eliminates the need to prefix column names with abbreviations (and removes the potential for running out of two & three-letter combinations).

yeah - I believe I have decided to drop the table prefix thing in the field name

>2) I'm of the old-style, Hungarian-notation column-naming school - "c" prefix for character, "i" for integer, etc. It has saved me countless hours of having to look up column types in other developers' stored procs. Plus it eliminates the possibility of reserved-word conflicts.

not as much of an issue for us as we are in vert app market. We're not dealing with unknown code and everything is well documented. I could see your point for a dev shop.

>3) I prefix PK columns "PK_" and foreign key columns "FK_" (usually with the same column name as the parent, unless the situation dictates otherwise). Again, it's self-defense, as I can tell instantly what the column is. The choice of prefixes is habit, since my case tool of choice names the columns that by default. As long as you have some pattern, you're okay.

what CASE tool is that? The ones I've seen want to fully migrate the key (same name both tables). Some even make it difficult to do anything else.

>One last habit I've adopted is to put the columns in alphabetical order. Helps to find columns in large tables easier, and since we use Hungarian notation, all like-type columns are grouped together (which makes it easy to double-check defaults, null acceptance, and so forth.

hmm - I've learned not to count on order in the physical table other than having keys up top. What order I have is more based on logical groupings of the fiels - i.e. Name, address, city, state, zip together

Thanks for your input - I'm interested in your case tool answer.

thanks,
Ken B. Matson
GCom2 Solutions
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform