Existují tři základní způsoby, jak vyřešit tento druh problému, protože omezení CHECK nemohou být založena na dotazu.
Možnost 1:Spouštěče
Nejjednodušším přístupem by bylo umístit spouštěč na TANK, který se dotazuje na TANKS a vyvolá výjimku, pokud LEVEL překročí CAPACITY. Problém s tímto druhem zjednodušeného přístupu je však v tom, že je téměř nemožné správně řešit problémy souběžnosti. Pokud relace 1 sníží CAPACITY, pak relace 2 zvýší ÚROVEŇ a poté se obě transakce potvrdí, spouštěče nebudou schopny detekovat porušení. To nemusí být problém, pokud se jedna nebo obě tabulky mění jen zřídka, ale obecně to bude problém.
Možnost 2:Materializovaná zobrazení
Problém souběžnosti můžete vyřešit vytvořením materializovaného pohledu ON COMMIT, který spojuje tabulky NÁDRŽE a NÁDRŽE, a poté vytvořením omezení CHECK pro materializovaný pohled, které ověřuje, že ÚROVEŇ <=KAPACITA. Můžete se také vyhnout ukládání dat dvakrát tím, že materializovaný pohled bude obsahovat pouze data, která by porušila omezení. To bude vyžadovat zhmotněné protokoly zobrazení na obou základních tabulkách, což přidá trochu režie na vkládání (i když méně než použití spouštěčů). Přesunutí kontroly na dobu potvrzení vyřeší problém souběžnosti, ale představuje trochu problém se správou výjimek, protože operace COMMIT nyní může selhat, protože se nezdařilo obnovení materializovaného pohledu. Vaše aplikace by musela být schopna tento problém zvládnout a upozornit uživatele na tuto skutečnost.
Možnost 3:Změňte datový model
Pokud máte v tabulce A hodnotu, která závisí na limitu v tabulce B, může to znamenat, že limit v B by měl být atributem tabulky A (místo nebo navíc k atributu tabulky B). Záleží samozřejmě na specifikách vašeho datového modelu, ale často to stojí za zvážení.