Skip site navigation (1) Skip section navigation (2)

Re: arc relationship [was: db design question]

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
On 23 Oct 2002 at 9:39, Josh Berkus wrote:
> 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!

In response to

pgsql-novice by date

Next:From: RobDate: 2002-10-24 09:46:05
Subject: Postgres and Sybase
Previous:From: Ludwig LimDate: 2002-10-24 05:15:39
Subject: Re: display functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group