Re: [pgsql-ru-general] несколько вопросов новичка (ограничения и индексы)

21 февраля 2011 г. 12:42 пользователь Dmitry E. Oboukhov
<unera(at)debian(dot)org>написал:

>
> DI> Проектная задача тривиальна - отношение "многие ко многим", как
> DI> и её реализация - 3 таблицы: server, resource и server_resource.
> Последняя
> DI> таблица (кстати, называйте как хотите, все равно это не сущность,
> DI> а лишь способ реализации "многих ко многим") содержит 2 столбца,
> DI> которые - суть внешние ключи - один "смотрит" в server, другой -
> DI> в resource. Первичный ключ данной таблицы как раз состоит из этих 2-х
> DI> столбцов. Полезно также создать индекс на тот столбец, который
> DI> входит в первичный ключ вторым (оптимизация). Первичный ключ
> DI> (он же, на самом деле, просто сочетание огранчений уникальности
> DI> и недопустимости значений NULL) и обеспечит ограничение целостости.
> DI> Уверяю, что реализовать лучшее ограничение целостности написанием
> DI> триггерной функции не удастся, как бы не старались. Да и зачем?
> DI> Оптимизация? Боязнь JOINов ? :-)
>
> нормализованный вариант понятен. суть в том что по логике приложения
> будет получаться join будет делаться *всегда*, соответственно отсюда и
> стремление к денормализации
>
В любом случае, это не правильное стремление. Нормальные формы
позволяют минимизировать избыточность. Чем не оптимизиация?
Рассматривать оптимизацию только с одной стороны - "скорость выборки" -
это не правильно. Да и вообще, как можно что-то ускорять, не
проведя массу тестов, результаты которых окажутся неудовлетворительными?
"Оптимизация", ведущая к деградации дизайна БД, неразумна.
Если так уж не хочется выполнять аггрегацию данных при каждой выборке,
можно хранить готовый массив, например, в таблице server, который
генерируется каждый раз при выполнении операций над таблицей
server_resource. Для решения этой задачи потребуется написать
триггерную функцию и создать триггер на таблицу server_resource.
Этот массив следует расценивать как некий кэш.

>
> DI> Нормализация имеет смысл. Почему вообще такой вопрос встаёт?
> DI> Жалко создать таблицу? :-)
>
> опять та же оптимизация, если мы не делаем запроса без JOIN'а,
> следовательно есть смысл выкинуть его перенеся поля в основную
> таблицу.
>
> ну может мне MySQL'ный опыт мешает :)
>
Если это так уж критично, то лучше определить 2-х столбцовый
внешний ключ (например - id, name) в дочерней таблице и
установить режим каскадного обновления данных (ON UPDATE
CASCADE).

>
> --
> . ''`. Dmitry E. Oboukhov
> : :’ : email: unera(at)debian(dot)org jabber://UNera(at)uvw(dot)ru
> `. `~’ GPGKey: 1024D / F8E26537 2006-11-21
> `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
>

--
// Dmitriy.