Re: Avoiding New Fields Causing Ambiguity Errors

On 10 May 2002 07:44:40 -0700, 71062.1056_at_compuserve.com (--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
>model.

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.Inglis_at_CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply

tosspam_at_aol.com abuse_at_aol.com abuse_at_yahoo.com abuse_at_hotmail.com abuse_at_msn.com abuse_at_sprint.com abuse_at_earthlink.com abuse_at_cadvision.com abuse_at_ibsystems.com uce_at_ftc.gov
						spam traps