From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us, JanWieck(at)yahoo(dot)com, pgman(at)candle(dot)pha(dot)pa(dot)us |
Subject: | Re: Megabytes of stats saved after every connection |
Date: | 2005-07-29 16:52:40 |
Message-ID: | 87y87p7dwn.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> writes:
> Hello again,
>
> Just to give a bit of background, in case it is useful: this is my family tree
> website, treefic.com. I have a schema for each user, each with about a dozen
> tables. In most cases the tables are small, i.e. tens of entries, but the
> users I care about are the ones with tens of thousands of people in their
> trees. The schemas are independent of each other. Example web page:
I would strongly suggest you reconsider this design altogether. A normal (and
normalized) design would have a users table that assigns a sequential id to
each user. Then every other table would combine everybody's data but have a
user id column to indicate which user that row belonged to.
If you don't believe there's anything wrong with your current system, consider
what it would look like to query your existing schema to find out the answer
to the question "how many users have > 1000 people in their tree". Or "how
many users have updated their tree in the last 7 days".
In a normalized database you really want one table for any given type of data.
Not hundreds of tables that contain the same type data but for different
people.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-07-29 16:58:34 | Re: GUID for postgreSQL |
Previous Message | John D. Burger | 2005-07-29 16:18:30 | Re: GUID for postgreSQL |