YulkaКороче, слишком многое приходится делать за СУБД...

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

mir mcureenabМногие задачи обеспечения целостности данных легко решаются с помощью хранимых процедур и тригеров (часто такие триггеры можно создавать автоматически).Она же ясно сказала, что ее интересует ссылочная целостность. ХП и триггеры тут не при чем.

Не вижу причины для возмущения. Целостность данных можно обеспечить как декларативными ограничениями, так и процедурно, с помощью ХП и триггеров.

mir mcureenabС другой стороны не стоит усложнять БД всякими ограничениями, делая её менее универсальной и меннее пригодной для хранения разных данных. Ведь можно делать приложения БД так, чтобы они корректно работали с теми данными которые удовлетворяют минимальным ограничениям.Мысль не понял. Если есть в предметной области бизнес-правило (ограничение целостности), которое можно заложить в БД, его нужно заложить. Всё.

Я привых различать "бизнес-правила" и "декларативные ограничения целостности".

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

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

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

Сахават Юсифов mir ChA mirЕсли есть в предметной области бизнес-правило (ограничение целостности), которое можно заложить в БД, его нужно заложить.Ээээ...Теоретически, Вы, скорее, правы, практически, далеко не все бизнес-правила можно описать стандартным механизмом ограничений без использования процедурного кода.А я разве говорил о способе реализации правил? Я лишь подивился странной мысли "не стоит усложнять БД всякими ограничениями".

Не стоит усложнять БД, если туда кроме Вас никто не полезет.

ИМХО, как раз наоборот. Свою персональную БД можно обвешать ограничениями как рождественское древо. Чтобы БД была полезной комуто ещё, ограничениями придётся пожертвовать.

mir mcureenabДекларативные ограничения целостности диктуются объективными свойствами данных. такой вещи, как объективные свойства данных, просто не существует. БД суть модель куска реального мира, а значит изначально условна. Назовите мне типичные свойства данных, которые вы считаете "объективными" и я думаю, что придумаю пример, где это будет не вполне так.

Это скорее говорит о том, что объективных свойств данных очень мало, гораздо меньше чем свойств определяемых текущими бизнес-правилами.

БД, несомненно, абстракция объектов реального мира. Но реальный мир объективен (по крайней мере эта теория до сих пор продуктивна).

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

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

mirВы же готовы за некую гипотетическую "гибкость" и "универсальность" БД (понимаемые вами как-то по своему) платить достоверностью. Бог в помощь. Иногда это можно. Но в основном -- недопустимо. Кому нужна "гибкая" и "универсальная" БД, в которой храниться, простите, всякое г@вно и мусор? На любителя.

Ограничения целостности в общем случае не обеспечивают достоверность данных, т.е. соответствие состояний БД и моделируемого объекта.
Достоверность определяется использованием данных и наличием обратной связи. Если данные нигде не используются, то их достоверность не проверяется. Если нет обратной связи, то обнаруженные несоответствия не исправляются.

mirЕсли дорогущий джип -- достоверность, то машина подешевле -- целостность. Ее мы вполне можем себе позволить. Целостность -- это такой суррогат достоверности. Чем данные целостнее, тем они достовернее. Если нет целостности, нет и достоверности.

Я не буду столь категоричен. В качестве исключения замечу, правила целостности тоже могут быть недостоверными, таким образом достоверные данные могут не отвечать правилам целостности и на практике такая ситуация не редкость.
Причины могут быть разные. От банальных ошибок проектирования, кодирования и развёртывания, до упрощения (точнее оптимизации) модели данных за счёт использования свойств бизнес-операций.

YulkaЧто касается ссылочной целостности, поддерживаемой современными СУБД, то из-за ее недостаточности очень хочется вообще от нее отказаться к чертовой матери (раз встроиться нельзя). Например, как только условия более жесткие, чем уникальность (уникальность-то по любэ), то СУБД будет мне проверять уникальность, а я поверх свои допусловия – очевидно, что мы дважды тратим машинное время :-(.

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

Если вопрос не решается существующими методами, может быть нужно откушать кофе, найти ошибку и исправить модель данных?
Может быть не стоит прогибать БД под приложение, а стоит сделать его так, чтобы оно корректно работало с имеющимися данными?