Re: Postgresql and programming

Поиск
Список
Период
Сортировка
От Jesus Aneiros
Тема Re: Postgresql and programming
Дата
Msg-id Pine.LNX.4.10.10006142150120.12944-100000@jagua.cfg.sld.cu
обсуждение исходный текст
Ответ на Postgresql and programming  ("T.J.Farrell" <T.J.Farrell@wanadoo.fr>)
Список 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 по дате отправления:

Предыдущее
От: Mark Stier
Дата:
Сообщение: optimization by removing the file system layer?
Следующее
От: Hrvoje Niksic
Дата:
Сообщение: Dropping tables