Re: Postgresql and programming - Mailing list pgsql-general

From Jesus Aneiros
Subject Re: Postgresql and programming
Date
Msg-id Pine.LNX.4.10.10006142150120.12944-100000@jagua.cfg.sld.cu
Whole thread Raw
In response to Postgresql and programming  ("T.J.Farrell" <T.J.Farrell@wanadoo.fr>)
List pgsql-general
Well I think the problem here is normalization which is more important
than perfomance. The anomalies of the first schema could take us into an
extremely poor situation, even in terms of perfomance. Could you imagine a
situation where you have 1 million records and you have to update the
author or editorname? How many replacements in the first case? Imagine the
same situation in the second case?

Jesus.

On Wed, 7 Jun 2000, T.J.Farrell wrote:

> Hello all,
>
> as usual in CS, there can be many ways to do the same thing.
> For instance, I can uppercase a string in a function in POstgreSQL or I can
> uppercase it before sending the query to the database. I am reading Bruce
> Monjian's book right now (page 204, Functions & triggers/triggers), and I am
> wondering in terms of performance and speed what way is prefered (option A
> or B).
>
> In terms of performance also, is it preferable to desing a database as:
>
> create table articles (
>             refarticle text,
>             title text,
>             authorID integer,
>             authorname text,
>             editorID integer,
>             editorname text,
>             ... etc...
>                 );
>
> OR :
>
> create articles(
>             refarticle text,
>             title text,
>             authorID integer,
>             editorID integer,
>             ... etc...
>                 );
>
> create table authors(
>                            authorname text,
>                             authorID integer,
>                             ...etc...
>                             );
>
> create table editors(
>                 editorID integer,
>                 editorname text,
>                 ...etc...
>                     );
>
> as the critical fields that searches will primarily be based on are obvious
> here.
>
> TIA.
>
> T.J.
>
> (P.S. some of you might remember design B from biblio.mdb :-) . )
>
>


pgsql-general by date:

Previous
From: Mark Stier
Date:
Subject: optimization by removing the file system layer?
Next
From: Hrvoje Niksic
Date:
Subject: Dropping tables