Re: Individual Type Code tables vs. one big one

mapsonp_at_ois.com.au (Peter Mapson) wrote:

>IMHO, having worked on systems which use both approaches, I'm firmly
>on the side of a generic code table with a type column.

What this really boils down to is a question of authority and responsibility.

The extra coding you complain about takes just a 'cookie cutter' approach to solve. The only reason you wouldn't want the cookie cutter approach is if there is some relevant business data manipulation that is specific to one or more of the code-sets. And this argues for it to be a separate table.

The real question here is this: should programmers have the authority and power to create new code-sets or should that ability and power be kept in a 'check and ballance' with a DBA or a DA?

If you believe that whiping up some code is always the solution to any problem, then you would want the single, generic code table.

If you believe that data has intrinsic value that must be protected and managed responsibly, then you would want a separate table for each validation code set.

Invariably, what one sub-system treats as just a valid code set, the next subsystem would want non-uniqe values associated with that code (turning that code into the primary key of a regular, business-information bearing table).

It is also a matter of perspective: which is more important to you:

1. to meet a short them deadline in the cheapest way regardless of the consequences to those who come after you
2. to responsibly manage the sum total of the data resources for the enterprise for which you work

   ---

'Keystroke'
KeystrkTX_at_AOL.COM Received on Sat Nov 16 1996 - 00:00:00 CET