Istnieją trzy podstawowe sposoby rozwiązania tego rodzaju problemu, ponieważ ograniczenia CHECK nie mogą być oparte na zapytaniu.
Opcja 1:Wyzwalacze
Najbardziej uproszczonym podejściem byłoby umieszczenie wyzwalacza na ZBIORNIK, który wysyła zapytanie do ZBIORNIKÓW i zgłasza wyjątek, jeśli POZIOM przekracza POJEMNOŚĆ. Problem z tego rodzaju uproszczonym podejściem polega jednak na tym, że prawidłowa obsługa problemów ze współbieżnością jest prawie niemożliwa. Jeśli sesja 1 zmniejszy POJEMNOŚĆ, to sesja 2 zwiększy POZIOM, a następnie obie transakcje zostaną zatwierdzone, wyzwalacze nie będą w stanie wykryć naruszenia. Może to nie stanowić problemu, jeśli jedna lub obie tabele są rzadko modyfikowane, ale ogólnie będzie to problem.
Opcja 2:widoki zmaterializowane
Problem współbieżności można rozwiązać, tworząc widok zmaterializowany ON COMMIT, który łączy tabele ZBIORNIK i ZBIORNIKI, a następnie tworząc ograniczenie CHECK w widoku zmaterializowanym, który weryfikuje, czy POZIOM <=POJEMNOŚĆ. Możesz również uniknąć dwukrotnego przechowywania danych, mając widok zmaterializowany zawierający tylko dane, które naruszałyby ograniczenie. Będzie to wymagało dzienników widoków zmaterializowanych w obu tabelach podstawowych, które dodadzą nieco narzutu do wstawiania (choć mniej niż przy użyciu wyzwalaczy). Przesunięcie sprawdzenia do czasu zatwierdzenia rozwiąże problem ze współbieżnością, ale wprowadza trochę problemu z zarządzaniem wyjątkami, ponieważ operacja COMMIT może teraz zakończyć się niepowodzeniem, ponieważ odświeżenie widoku zmaterializowanego nie powiodło się. Twoja aplikacja musiałaby być w stanie poradzić sobie z tym problemem i powiadomić użytkownika o tym fakcie.
Opcja 3:Zmień model danych
Jeśli masz wartość w tabeli A, która zależy od limitu w tabeli B, może to wskazywać, że limit w B powinien być atrybutem tabeli A (zamiast lub oprócz atrybutu tabeli B). Zależy to oczywiście od specyfiki Twojego modelu danych, ale często warto to rozważyć.
