Има три основни начина за решаване на този вид проблеми, тъй като ограниченията на CHECK не могат да се основават на заявка.
Опция 1:Задействания
Най-опростеният подход би бил да поставите тригер на TANK, който отправя запитвания към TANK и хвърля изключение, ако НИВОТО надвишава CAPACITY. Проблемът с този вид опростен подход обаче е, че е почти невъзможно да се справят правилно с проблемите с паралелността. Ако сесия 1 намали КАПАЦИТЕТА, тогава сесия 2 увеличава НИВОТО и след това и двете транзакции се ангажират, тригерите няма да могат да открият нарушението. Това може да не е проблем, ако една или и двете таблици рядко се променят, но като цяло ще бъде проблем.
Опция 2:Материализирани изгледи
Можете да разрешите проблема с едновременността, като създадете материализиран изглед ON COMMIT, който се присъединява към таблицата TANK and TANKS и след това създадете ограничение CHECK на материализирания изглед, което проверява, че LEVEL <=CAPACITY. Можете също така да избегнете съхраняването на данните два пъти, като материализираният изглед съдържа само данни, които биха нарушили ограничението. Това ще изисква материализирани регистрационни файлове за изглед и на двете основни таблици, което ще добави малко излишни разходи към вмъкванията (макар и по-малко от използването на тригери). Натискането на проверката до време за извършване ще реши проблема с паралелността, но въвежда малко проблем с управлението на изключенията, тъй като операцията COMMIT вече може да се провали, защото материализираното опресняване на изглед е неуспешно. Вашето приложение трябва да може да се справи с този проблем и да предупреди потребителя за този факт.
Опция 3:Променете модела на данни
Ако имате стойност в таблица A, която зависи от ограничение в таблица B, това може да означава, че ограничението в B трябва да бъде атрибут на таблица A (вместо или в допълнение към атрибут на таблица B). Зависи от спецификата на вашия модел на данни, разбира се, но често си струва да се обмисли.
