Re: Database design - best practice

Поиск
Список
Период
Сортировка
От Bèrto ëd Sèra
Тема Re: Database design - best practice
Дата
Msg-id CAKwGa__-oh_J6zr0jYGQ0GqeiCL_OkFq83Judd0rXE92wa7NnQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Database design - best practice  (Willem Leenen <willem_leenen@hotmail.com>)
Список pgsql-performance
Hi Kristian,

> " I can't see why it would make sense to put that into a separate table and
> join in the values "
> You don't normalize for performance. People DEnormalize for performance.

Yes. In short, you seem more of a developer than a RDBMS guy. This is
not a personal fault, but it's a *very* dangerous state to be in and
you should address the problem asap. Erase from your head all you
could possibly know in terms of "putting it into a file" and read very
basic texts about normal forms. Like this:

http://en.wikipedia.org/wiki/Database_normalization

As already said by Willem, learn to test your stuff. There is a
\timing command in psql, use it.

For example (addressing your other post), you want to check how long it takes to
UPDATE "adverts"
SET
  "last_observed_at" = '2012-11-28 00:02:30.265154',
  "data_source_id" ='83d024a57bc2958940f3ca281bddcbf4'
WHERE
  "adverts"."id" IN ( 1602382, 4916432, ...... 3637777 ) ;

as opposed to

UPDATE "adverts"
SET
  "last_observed_at" = '2012-11-28 00:02:30.265154',
  "data_source_id" ='83d024a57bc2958940f3ca281bddcbf4'
WHERE
  "adverts"."id" = 1602382 OR
  "adverts"."id" = 4916432 OR
   ......
  "adverts"."id" = 3637777;

My 5 pence
Bèrto
--
==============================
If Pac-Man had affected us as kids, we'd all be running around in a
darkened room munching pills and listening to repetitive music.


В списке pgsql-performance по дате отправления:

Предыдущее
От: Willem Leenen
Дата:
Сообщение: Re: Database design - best practice
Следующее
От: Shaun Thomas
Дата:
Сообщение: Re: Optimize update query