Re: database design best pratice help

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(at)ymail(dot)com> wrote:

> Jose Soares <jose(dot)soares(at)sferacarta(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>