Re: Attributes Names Standards

>I trying to argue a point and need a little help. Some "micro-manager"
>wants to included a column type into the column name like : INT_AGE,
>indicating that AGE column has a type INT. This is crazy! What if
>someone decides that a smallint (sybase) would be better. Application
>code would have to be modified and recompiled, etc if this was to happen.
>So any solid reasons NOT to do this besides "its just no done"?
>

This IS a terrible idea--so terrible that it's difficlt for me to imagine any reason it might be suggested. Does this micro-manager possibly think this saves someone "looking up" the data-type? At any rate, it is a bad idea--the attribute name should reflect the meaning of the property of the entity that its related table is supposed to represent. Nothing more, nothing less. And some people would argue that attribute as a concept is quite distinct from the idea of a "data element". It's perhaps best to recall the original relational concept of a domain: a NAMED set of values that attributes may assume. A good example might be a Week_Days domain, which includes exactly seven values (at this level, you don't worry about whether the seven values are strings, or some enumerated type--that's a "mere implementation detail"). Unfortunately, current commercial DBMSs don't support domains--they give you a small set of low-level data types that are similar to what you get in a programming language: string, integer, and few "fancy" types like "date".

Now let's introduce the concept of data element. A de, then, is the set of all columns -- we're now talking about implementation details -- with the same name & domain. For example, BED_SIZE where the domain is the set of all "legal" bed sizes. Since domains aren't supported, we'll have to pretend (in fact, BED_SIZE will probably be implemented as an integer, and all the apps. that access it will have to "know" something about what constitutes a "legal" bedsize--but we wish the DBMS would do this for us.) Thus, the column name should be BED_SIZE, and that's it--not BEDSIZE_INT. Suppose we get a new version of the DBMS that offers domain support? Then BED_SIZE would no longer be implemented as an integer. Or at some point, we may want to use a real number instead. It doesn't matter--the name of the column should tell you something about the meaning of the property & nothing about how it's implemented. If you do, this is called "overloading the name" & it's ALWAYS bad--because it becomes difficult to separate the various things the name represents, and these meanings can change.

-- 
   Vince Ventrone
   The MITRE Corporation       "...In my opinion, there's nothing
   Bedford, MA 01730           in this world beats a '52 Vincent
   vav_at_mitre.org               and a redheaded girl."  -- Richard Thompson