Hello, Tonal!
Tonal wrote:
Собственно с view-ами я похоже погорячился. Проблема несколько шире:
Как и где задавать ограничения охватывающие несколько таблиц.
Сейчас можно это решить с помощью ограничений на каждую из таких таблиц,
но это неудобно т.к. нельзя нарисовать одно выражение и сдублировать для
каждой таблицы.
В 2.1 можно, вынести такие проверки в триггер TRANSACTION COMMIT.
Соответственно, на этом же можно реализовать и механизм проверки
ограничений для нескольких таблиц.
это ты перегрелся слегка. цитирую с sql.ru:
http://www.sql.ru/forum/actualthread.aspx?bid=10&tid=471584&pg=7#4679218
ModelR:
Самое забавное, что многие здесь упомянутые ограничения масштаба БД
прекрасно выражаются на SQL. Типа
- склад не может в себе (в подчинении??) содержать цех,
- у начальника не больше 7 подчиненных,
- если накладная по безналу и позиций больше 100, то ее должен был
подписать не менее чем старший дворник.
Но ни одна из (известных мне) РСУБД не позволяет использовать таковые
выражения как декларативные ограничения целостности. Кроме ссылочной
целостности - никаких чудес.
А почему? ИМХО вовсе не из-за слабости выразительных средств того же
SQL, а во-первых из-за той вычислительной нагрузки, которой тогда
придется рулить, а во-вторых из-за неизбежной сериализации запросов, и
нафига тогда столько сил убито на параллелизм работы пользователей?
Не..., оставим это приложениям и серверам приложений а наше (СУБД) дело
- данные.
Реальныо о причинах Оракл с Микрософтом мне как-то забыли доложить, но
вполне вероятно.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
