Серж1. Мне интересно на сколько часто встречаются системы построенные на таких принципах?

2. Отказались ли от них в силу неудобств или разработка так и продолжается?

3. Какого типа задачи решались (у нас в основном массированная закачка из других систем и аналитика)?

4. Были эти системы централизованные или распределенные (имеются в виду серверная часть)?

5. И дает ли это ощутимый выигрыш в производительности (за счет отсутствия проверок ссылочной целостности)?

Говоря за свою...
1. Несколько сотен инсталляций.
2. Нет конечно. Ведь всё работает.
3. OLTP.
4. БД централизованная. Но система взаимодействует с кучей внешних систем (дилеры, приём платежей).
5. Скорее нет, всё равно какие то проверки приходится делать, но менее эффективными способами. Другое дело, когда исходные данные уже проверены.

NOT NULL мы конечно используем.
Для реальных данных сложно вводить какие либо ограничения. Рано или поздно в силу изменений в бизнесе или от бардака находятся такие сведения, которые не проходят проверку. В лучшем случае производится разбирательство и исправление, в худшем, в систему вводятся фальсифицированные сведения (лишь бы съела).
В такой ситуации хуже всего удалять ограничения целостности, поскольку разработчики (чтобы упростить себе жизнь) уже могли завязать на них свой код.

В общем, я постепено прихожу к мнению, что использовать системные механизмы СУБД (такие как декларативные ограничения целостности, транзакции) нужно для реализации системных механизмов приложения (например для реализации элементарных изменений объекта, или для поддержки пользовательских типов данных), где правила диктует не бизнес а разработчик.
Бизнес транзакции, проверки бизнес правил должны стать заботой приложений, которые изменять гораздо легче, чем БД с большой историей. Программировать приложения для таких БД сложнее, однако и возможностей для конфигурирования и модификации системы становится значительно больше.

Valentin Kotelnitski
guest_20040621,
ты как считаешь, успешный опыт обуреваем жаждой столкнуться с проблемами?




Голословные утверждения. Лично я не слышал, чтобы какой нибудь программист повесился из-за своей ошибки.

Ограничения целостности это палка о двух концах. С одной стороны они повышают качество данных, с другой, они могут мешать приложениям выполнять свои функции. В частности ошибочно введённые ограничения, это такая же проблема, как кривые данные. Отличаются только подходы к исправлению ситуации.

Valentin Kotelnitski, да не он первый. Я поначалу тоже думал, что ограничения целостности это сплошное благо. Но когда создал такое ограничение, которое по ходу ещё и не позволяло удалять записи усомнился. :) Много гемора было с тестированием, потому как приходилось генерить только исключительно правильные данные и применять их правильными транзакциями. Потом, так же как автор, столкнулся с системой, где тоже на мой взгляд было много неправильного, но система работала и работает и работать будет. Постепенно вник в тему и всё встало на свои места.

Все эти штучки, как болты и заклёпки. Сборка на болтах ремонтопригодна, но ненадёжна, на заклёпках надёжнее, но разбирать сложно, а монокок это вообще верх функционального совершенства, но если он ломается, то ремонту не подлежит и модернизировать его нельзя. Коммерческий успех системы зависит не от количества ограничений целостности в БД, а от того, насколько грамотно они применяются или не применяются в тех или иных ситуациях.