RE: Physical Database Design - Code Tables

Ken,
 
Let's not put words into Dennis's mouth, that was my post you replied
to...;-)
 
Also, see this:
http://tkyte.blogspot.com/2006/11/worst-practices.html
 
-Mark
 
--
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: Ken Naim [mailto:kennaim@xxxxxxxxx] 
Sent: Tuesday, November 21, 2006 5:17 PM
To: Bobak, Mark; oracledba.williams@xxxxxxxxx; jkstill@xxxxxxxxx
Cc: paulastankus@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Physical Database Design - Code Tables


Dennis I never thought of it like that, we can make things even simplier
by having one table in the database and putting all all the data in your
blob field.. :-)
 
 
________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Bobak, Mark
Sent: Tuesday, November 21, 2006 4:42 PM
To: oracledba.williams@xxxxxxxxx; jkstill@xxxxxxxxx
Cc: paulastankus@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Physical Database Design - Code Tables
 
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: