Павел Воронцов

Ну нельзя же быть настолько безграмотным в самом деле.. Вопрос производительности относится к проектированию опосредованно. Проектировать БД нужно, исходя из принципов построения баз данных (реляционная теория, нормальные формы).

Вы, сударь, похоже невнимательно читаете мои посты. Написано было "КРИТИЧНО".
Проектировать базы нужно не "исходя из принципов построения", а исходя из требований заказчика с использованием упомянутых принципов. При этом надо помнить пословицу: "Научи дурака Богу молиться - он себе весь лоб расшибет".

А если конкретная СУБД конкретного производителя настолько слаба, что на её работу влияют те самые принципы, на которых она ДОЛЖНА БЫТЬ построена, то лучше выкинуть такую систему.

Гхм. Это ты перед заказчиком можешь выеживаться. И объяснять ему что выбранная им система никуда не годится, и он должен купить новую, более производительную, по той простой причине, что ты не сможешь спроектировать в соответствии с теорией.
Бывает, конечно, что заказчик хочет на грош пятаков наменять. Но бывают и случаи, когда нужно привязывать разрабатываемую систему к уже работающей. Еще бывают случаи, когда дорог каждый тик процессора. Для примера: сбор и обработка информации с системы датчиков в реальном режиме времени. В этом случае foreing key только тормозит, как и check.

Павел Воронцов

Я бы сказал совсем не так - "Check и Constrains НЕ нужно использовать только тогда, когда это очень критично". В этом наше различие, только и всего. )

Можно и так сказать. Но опять же - не стоит увлекаться. Все таки производительность - последнее качество базы. Да и прежде чем накладывать ограничения стоит задаться вопросом "А оно это нать?" :) В то же время иногда это значительно облегчает как проектирование и сопровождение (развитие). Foreing key с опцией delete cascade значительно облегчит код хранимых процедур и, соответственно, оптимизирует их выполнение.

Павел Воронцов

Jinn:

Я бы скорее задался вопросом "А оно нать?" при попытке удаления того или иного ограничения. Безусловно, производительность - важное и порой определяющее качество базы. Но всё же основной её (базы) задачей является реализация бизнес-логики. Собственно для того всё это (реляционную теорию-SQL-современные СУБД сиречь сервера) и придумывали.

В общем - пришли к консенсусу. Мы с тобой идем к одной цели с разных сторон: ты отсекаешь лишнее, а я добавляю необходимое. Конечный результат будет, практически, одинаков :)