From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Jose Soares *EXTERN*" <jose(dot)soares(at)sferacarta(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: database design best pratice help |
Date: | 2013-01-28 10:13:25 |
Message-ID: | A737B7A37273E048B164557ADEF4A58B057ABE30@ntex2010a.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Leif Jensen | 2013-01-28 10:19:42 | Rules on views - Changes from 8.4 to 9.1 ? |
Previous Message | Thomas Kellerer | 2013-01-28 10:02:21 | Re: database design best pratice help |