Re: Physical Database Design - Code Tables

I'm usually following some kind of a golden mean.
One can say also I'm suffering from disadvantages of both approaches :)

For classifiers that are either bigger or tend to change for example
countries, parts of addresses, occupation type, currencies,
nationalities, languages, payment types, document types I'm creating
separate tables where one can enforce FKs, change values etc.

For classifiers that are small or part of application and cannot be
changed without code change as well, I create one common table, for
example for sex, booleans, some application-important statuses, person
statuses (live/dead/missing).
To enforce valid values check constraints can be used in this case,
because these are values that usually don't change and even more - I
as the application developer have to know that these values are
changed, because some functionality depends on some precise values.

I assume this approach is legacy for me from Oracle Designer usage times.

Gints Plivna
http://www.gplivna.eu


2006/11/21, Paula Stankus <paulastankus@xxxxxxxxx>:
Guys,

I know that for developers having the generic, one-size-fits-all codetable
is easier for them to code.  However, I am very worried that having one
generic codetable for all applications, all tables and all code fields could
cause serious contention.

Am on off here and if not, what is the best way to find out about
contention.

Thanks,
Paula
--
http://www.freelists.org/webpage/oracle-l


Other related posts: