RE: Physical Database Design - Code Tables
- From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxxxxx>
- To: <oracledba.williams@xxxxxxxxx>, <jkstill@xxxxxxxxx>
- Date: Tue, 21 Nov 2006 16:42:14 -0500
Dennis,
That's no problem, then you just need a DATA_TYPE column, and make the
VALUE column a VARCHAR2, or, even better a BLOB! Then you can make
every column any type you'd like, and just use the DATA_TYPE column to
keep track of what kind of data is stored there! ;-)
-Mark
PS No, I'm *not* serious! That's why I put a smiley at the end of the
sentence!
--
Mark J. Bobak
Senior Oracle Architect
ProQuest Information & Learning
There is nothing so useless as doing efficiently that which shouldn't be
done at all. -Peter F. Drucker, 1909-2005
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Dennis Williams
Sent: Tuesday, November 21, 2006 4:30 PM
To: jkstill@xxxxxxxxx
Cc: paulastankus@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: Physical Database Design - Code Tables
Paula,
One issue I don't see mentioned is the number of columns. In my
experience, some codes tables have a different number of columns than
others, and those columns may have different properties (data type,
column name, etc.). If you use a single codes table, then all codes must
have the same columns. If at a later point, some codes are found to need
an additional column, then all codes will get the added column. If you
add that column, then you have to hope that all the application code
will be unaffected. This isn't probably a big deal, but I think it
points to the non-normalized situation that a shared code table gets you
into.
Dennis Williams
Other related posts:
