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