Re: database design best pratice help

> In my db I have about one hundred tables like this:
>
> code
> description
>
> To avoid to have a so great number of similar tables in the db
> I wonder if it is a good idea to unify all these tables in one big
> table like this:
>
> id
> code
> table_ name
> description

Bad idea.

E.g. how do you want to warrant (integrity!) that records in
the table <table_x> point only to codes that are valid for this table.

To implement this as a constraint and at object level would create an
obfuscated mess.

Besides, that "id" column is a bad idea as well. The primary key of such
a table would have to be composed of "code" and "table_name", of course.

> 2. only one controller to manage the table

With any reasonable database framework that I know of, it's
ridiculously trivial to declare these codes as de-normalises "one to
many"-attributes at the object level. No need to implement *any*
"controllers" at all.

Sincerely,

Wolfgang