|
|
Posted by David Portas on 12/28/05 15:41
Cecil wrote:
> OK, can you help me to understand why ID and name are poor field
> choices. I am asuming it has to do w/ ambiguity. I always qualify
> fields w/ their table names for precisely this reason, so I always
> concidered something like Category.categoryID to be very redundant.
>
> I prefer Category.ID and Category.name. The only time I would write
> CategoryID is if it was a foreign key linking to the "ID" field in the
> Category table.
>
> If you believe this to be poor practice, would you please explain why?
> Thanks.
Naming conventions are supposed to aid understanding, verification,
interchange, and ongoing maintenance of code by others. Generally
accepted standards and conventions therefore ought to be more important
than personal preferences. Quote: "Any fool can write code that a
computer can understand. Good programmers write code that humans can
understand." (Martin Fowler). The same applies to your data model.
There is in fact an international standard for naming data elements:
http://metadata-standards.org/
One principle that's very widely used and that works well is that every
single data element should have a unique name in your database schema.
That means that foreign keys usually have the same name as the column
that they reference and that most column names won't appear in more
than one table except where they are keys or part of compound keys.
The advantages of using unique names are many:
- When maintaining schema and code you can easily search for column
name references in your code because each column has a unique name.
Your idea of qualifying each with the table name won't work because in
correlations and multiple joins to the same table you may be forced to
use aliases rather than table names. That means you can never reliably
search for a particular column. You'll have to manually check for each
occurence of "NAME" to see if it's the right one.
- Types and constraints can be defined and checked by column name
throughout the database. This is ideally suited to systematic auditing
of the schema, something which ought to be part of any implementation.
- Data dictionaries can be smaller and simpler to use by referencing
each element name rather than each table and name.
- Your code will be more readable if you use short aliases but that
only helps if you use concise and meaningful column names.
- Data interchange with XML for example is also made easier if you use
unique names for data elements.
- You'll be much less likely to clash with present and future reserved
keywords because most keywords are simple nouns or verbs whereas the
column names that are likely to conflict with them are usually
compounds.
--
David Portas
SQL Server MVP
--
Navigation:
[Reply to this message]
|