From: | "Jules Alberts" <jules(dot)alberts(at)arbodienst-limburg(dot)nl> |
---|---|
To: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: arc relationship [was: db design question] |
Date: | 2002-10-24 08:45:50 |
Message-ID: | 200210240854.g9O8sYE2008589@artemis.cuci.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
On 23 Oct 2002 at 9:39, Josh Berkus wrote:
<snip>
> 1) I am not reccomending that you use this approach for addresses --
> the standard relational model will serve your purposes, so there's not
> reason to get creative. I was reccomending that you try the "flexible
> child" approach *only* for the BLOB reference table.
OK, I'm convinced. I will apply the "arc" only when there is no other
way. For the addresses I will use the relational method.
> 2) In answer to your question: Imagine that I have 5 tables, clients,
> employees, invoices, orders, and payments. Imagine that each table
> has roughly 20,000 rows. Each table also has a row in the "mod_data"
> table. If I want to query the mod_data for a particular client, then
> the database has to search 100,000 rows, not the 20,000 it would search
> if the mod_data were directly in the clients table. get it?
>
> > Do you have an URL to such systems? I'm not familiar with them, I
> > guess
> > you don't mean journalling filesystems? TIA!
>
> I'm talking about triggers or other mechanisms that record each change
> to the database records into a permanent archive for auditing purposes.
Oh, I see.
> > With the info I have so far, I plan to work like this:
>
> See above. As I said before, I feel that the "flexible child" approach
> is a *bad* approach for storing the addresses. I just suggested it
> for the BOLBs. For the addresses, see my first e-mail to you on the
> topic.
I will, thanks again for all your help!
From | Date | Subject | |
---|---|---|---|
Next Message | Rob | 2002-10-24 09:46:05 | Postgres and Sybase |
Previous Message | Ludwig Lim | 2002-10-24 05:15:39 | Re: display functions |