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

Re: update == delete + insert?

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Jaime Casanova <systemguards(at)gmail(dot)com>
Cc: "Craig A(dot) James" <cjames(at)modgraph-usa(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: update == delete + insert?
Date: 2006-03-21 11:23:48
Message-ID: 20060321112348.GE15742@pervasive.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Mon, Mar 20, 2006 at 08:38:15PM -0500, Jaime Casanova wrote:
> On 3/20/06, Craig A. James <cjames(at)modgraph-usa(dot)com> wrote:
> > Design 1:
> >    create table a (
> >      id integer,
> >      frequently_updated  integer);
> >
> >    create table b(
> >      id integer,
> >      infrequently_updated_1 integer,
> >      infrequently_updated_2 integer,
> >      infrequently_updated_3 integer,
> >      ... etc.
> >      infrequently_updated_99 integer);
> >
> > Design 2:
> >    create table c(
> >      id integer,
> >      frequently_updated  integer,
> >      infrequently_updated_1 integer,
> >      infrequently_updated_2 integer,
> >      infrequently_updated_3 integer,
> >      ... etc.
> >      infrequently_updated_99 integer);
> design 1 is normalized and better
> design 2 is denormalized and a bad approach no matter the RDBMS

How is design 1 denormalized?

> "What they (MySQL) lose in usability, they gain back in benchmarks, and that's
> all that matters: getting the wrong answer really fast."
>                            Randal L. Schwartz

Where's that quote from?
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

In response to

Responses

pgsql-performance by date

Next:From: Jim C. NasbyDate: 2006-03-21 11:27:59
Subject: Re: Migration study, step 1: bulk write performance
Previous:From: Mark KirkwoodDate: 2006-03-21 11:03:26
Subject: Re: Best OS & Configuration for Dual Xeon w/4GB & Adaptec

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