Re: несколько вопросов новичка (ограничения и индексы)
От | Dmitry E. Oboukhov |
---|---|
Тема | Re: несколько вопросов новичка (ограничения и индексы) |
Дата | |
Msg-id | 20110221094211.GB9763@apache.rbscorp.ru обсуждение исходный текст |
Ответ на | Re: [pgsql-ru-general] несколько вопросов новичка (ограничения и индексы) (Dmitriy Igrishin <dmitigr@gmail.com>) |
Список | pgsql-ru-general |
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 будет делаться *всегда*, соответственно отсюда и стремление к денормализации DI> Нормализация имеет смысл. Почему вообще такой вопрос встаёт? DI> Жалко создать таблицу? :-) опять та же оптимизация, если мы не делаем запроса без JOIN'а, следовательно есть смысл выкинуть его перенеся поля в основную таблицу. ну может мне MySQL'ный опыт мешает :) -- . ''`. Dmitry E. Oboukhov : :’ : email: unera@debian.org jabber://UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Вложения
В списке pgsql-ru-general по дате отправления: