Re: Postgresql and programming - Mailing list pgsql-general

From Ron Peterson
Subject Re: Postgresql and programming
Date
Msg-id 39478CF4.EFD9711D@yellowbank.com
Whole thread Raw
In response to Postgresql and programming  ("T.J.Farrell" <T.J.Farrell@wanadoo.fr>)
Responses Re: Postgresql and programming  (Richard Harvey Chapman <hchapman@3gfp.com>)
List pgsql-general
If you're only consideration is raw performance of lookups on text
fields, I suppose there might be some measureable performance advantage
in putting everything in one table, but I doubt you'd really notice the
difference.  If you *did* do this, what is the significance of the
authorID field?

Normalize, normalize, normalize.  Use a relational database for it's
strengths.  Don't duplicate data.

"T.J.Farrell" wrote:
>
> 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...
>                     );

________________________
Ron Peterson
rpeterson@yellowbank.com

pgsql-general by date:

Previous
From: Ron Peterson
Date:
Subject: Re: Timestamp and compatiblity with MySQL
Next
From: Ron Peterson
Date:
Subject: Re: large text fields?