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

Re: Table Relationships

From: Andreas Kostyrka <andreas(at)mtg(dot)co(dot)at>
To: Victor Yegorov <viktors(dot)jegorovs(at)nordlb(dot)lv>
Cc: Jeandre du Toit <jeandre(at)itvs(dot)co(dot)za>,pgsql-performance(at)postgresql(dot)org
Subject: Re: Table Relationships
Date: 2003-06-12 09:32:09
Message-ID: 1055357830.5850.5.camel@andi-lap (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Fri, 2003-05-30 at 12:10, Victor Yegorov wrote:
> Take a look at situation from another side.
> Let's say: You own a store and have 3 customers and 5 products on your
> store. All you going to keep in DB is track of all purchases.
> So, each time a customer will by a product, an new record will be added.
> What this means:
> 1. Customer's name will be repeated as many times, as many purchases he had
>    made. The same for each of products. In real world, you'll have about
>    10,000 customers and about 100,000 products. Do you have enoght space on
>    your disks to store all that stuff?
Well, to play the devil's advocate, to do it correctly, you should
probably store the customer data duplicate (one in the main record, and
once in the purchase order). If you do not, you'll get an ERP system
that is incapable to reproduce work done, which is basically a BAD
THING(tm) :)

> 2. Some of your customers decided to change it's name. What you're going to
>    do? If you're going to insert new purchases of that customer with he's new
>    name, then in all turnover reports you'll have to specify both:
>    old name and new one. If he will hange his name again - again, all
>    reports are to be updated.
Well, again, a purchase order should keep records -> it shouldn't
magically change the name or address of the customer, just because the
customer moved.


In response to

pgsql-performance by date

Next:From: Patrick HatcherDate: 2003-06-12 16:33:34
Subject: new monster box CONF suggestion please
Previous:From: pginfoDate: 2003-06-12 04:48:27
Subject: Re: left join performance problem

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