database design best pratice help

I'll answer with the same things I did on the Oracle list :)

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

The advantages are:

1. only one table in the db instead of 100

That's not an advantage.

2. only one controller to manage the table

Why? You can also have a single controller with many tables.

With a single table the controller needs to know the code. With multiple tables the controller needs to know the table name.
I don't see any difference there.

Is there any negative point that I don't see?

Yes, you can't prevent storing the "wrong" code in a related table as you cannot have a foreign key to it.

Assume you have a list of codes for "order status" and a list of codes for employee status. With two lookup tables (and the proper foreign keys) you can make sure that only a valid employee status is stored in the employee table.

With the single table you can't prevent storing a value for "order status" as the employee table.

Your design is an anti-pattern which has a name: "one true lookup table".

Thomas

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Jose Soares wrote:

I have a question about database design best pratice.

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

The advantages are:

1. only one table in the db instead of 100
2. only one controller to manage the table

Could this be a way to enhance db performance?
Is there any negative point that I don't see?

If the resulting table grows to be big, that might be
a problem. Imagine that a query has to do a sequential scan
for a certain query.

Also, are there no foreign key constraints between tables?
If no, the design is questionable. If yes, how would you
handle them?

I guess it depends on what your application does, but I
wouldn't merge the tables. One hundred tables are not so
terribly many.

Yours,
Laurenz Albe

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Jose Soares <jose.soares@sferacarta.com> wrote:

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

Could this be a way to enhance db performance?

No.  It could easily hurt performance, and will create a mess of
your data.

Is there any negative point that I don't see?

For starters you can't use foreign keys to ensure data integrity.

I would not only leave the separate tables, but I would create a
separate domain for the code column of each, to be used everywhere
a code is of that nature.

I recommend reading up on concepts for normalizing a relational
database.  If you mix different logical types of data in one
column, you don't even meet the requirements of first normal form,
and reduce the ability to cleanly apply relational concepts to your
data.

-Kevin

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Yes. The general rules are:

Many normalized tables. OK.
Denormalizing simply to reduce the number of tables. Not OK.

- Bob

On Mon, Jan 28, 2013 at 1:47 PM, Kevin Grittner <kgrittn@ymail.com> wrote:

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general