Re: Naming Convention for Columns
Posted in 1998
Topics: Server Administration, Data Types & Schema Design
Oh, I can resist a religious battle Seriously, I would like to toss out some of our "arrived" at standards (and we have lived thru 2 generations now). What follows are bullets of what we do and I tried to explain some of it... -I also vote for the SAME NAME in all tables... (where a PK/FK relationship exists) -I also use 'table qualified' name for the PRIMARY key ONLY (i.e. Bank.BankKey, Customer.CustomerKey). The only quasi-exception is where there are TWO or more relationships between two tables (happens once every 3rd ERM/project) - when that happens the relationship 'meaning' adds to the qualification of the name. -nonkey attributes can exist without the table name... and YES, we have several attributes called "NAME" (Bank.name, Customer.Name, etc...). What also happens that when someone references a non key attribute, the table name is USUALLY required to identify the attriubte, so why repeat it. -Notice in the above examples, we spell out the names. Now that we are away from the 18 byte limit (given SQLServer) and yes, I jeopordize my backward compatibility with DB2, but...... (isn't DB2 getting to that point soon anyway?). Our rule is "simple, but readable" - we also assume ANY user (by definition) has a basic understanding of the logic/data (this doesn't include any complexities - just what planet they are looking at) -We use capital letters to delinate major words (see examples above) -We still use the OLD concept of TYPING the attributes (Text, Date, Time, Number, Percent, Volume, Code, etc) and have exceptions (like SSN, Name, etc (a.k.a. user defined data types)) We had several major points that lured us away from our old standards...(that you may or may not want to consider) 1. End Users (make it easy to understand and obvious as HECK) 2. PC reporting tool (end users) and code generators, no one types anymore ( it is 'point and click' or 'cut and paste'), relationships are click and drag (remember "same name"). Think of how the end users will see and use the data (not just the programmers.... no matter how hard they whine (yes I am a DBA)) 3. NOTHING exists in a vacuum. Attributes, tables, constriants, user defined data types... they all exist in relationship to one another... in the system catalog. Not that we query that much ... we use the GUI tools to show us everything. In other words why