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_at_yahoo.com>:
> 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