Re: Avoiding New Fields Causing Ambiguity Errors

From: Brian Inglis <>
Date: Thu, 16 May 2002 14:14:56 GMT
Message-ID: <>

On 10 May 2002 07:44:40 -0700, (--CELKO--) wrote:

>>> 1. Different entities happen to have the same kind of data. Common
>examples include Title and Status. Almost any entity you can think of
>may have a title
>or status field (or synonyms like "name", "description", etc.) <<
>Okay, I understand qualifiying these general words with an additional
>word or two like "invoice_status" because they do NOT have the same
>kind of data element -- I cannot do the same things with
>"invoice_status" as I can with "order_shipping_status". Look up ISO
>11179 Metadata specs on creating data element names; good stuff.
>>> 2. Key fields. I like the convention of "x_ref" for foriegn keys
>and "x_id" for the primary key. <<
>ARRRGHHH! Stop that at once! You are telling me what the column does
>in this particular table and not what it means in the logical data

Used databases designed like that -- hate it -- get names like vsol_so_st_code where it should really just be st_code. We don't care how you derived it when the database was designed; the relationship may be transitive via various tables' FKs, but there is also a direct FK relationship between that table and the code table!
Pain in the ass to remember whether or what prefix is used in a table.
If you prefix a column name, you should prefix it the same everywhere, like the meaningless roots (name, description, status, id, etc.) to give a meaningful unique column name that is used everywhere.
The rest of the meaning can be provided by column comments internally and database documentation externally, which I notice tends not to exist for these types of "fully self-documenting design".


Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply
						spam traps
Received on Thu May 16 2002 - 16:14:56 CEST

Original text of this message