Er zijn drie basismanieren om dit soort problemen op te lossen, aangezien de beperkingen van CHECK niet kunnen worden gebaseerd op een zoekopdracht.
Optie 1:triggers
De meest simplistische benadering zou zijn om een trigger op TANK te zetten die TANKS opvraagt en een uitzondering genereert als het LEVEL CAPACITY overschrijdt. Het probleem met dit soort simplistische benadering is echter dat het bijna onmogelijk is om gelijktijdigheidsproblemen correct af te handelen. Als sessie 1 de CAPACITEIT verlaagt, dan verhoogt sessie 2 het NIVEAU, en vervolgens worden beide transacties vastgelegd, triggers kunnen de overtreding niet detecteren. Dit is misschien geen probleem als een of beide tabellen zelden worden gewijzigd, maar over het algemeen zal het een probleem zijn.
Optie 2:Gematerialiseerde weergaven
U kunt het gelijktijdigheidsprobleem oplossen door een gerealiseerde ON COMMIT-weergave te maken die de tabellen TANK en TANKS samenvoegt en vervolgens een CHECK-beperking te maken voor de gerealiseerde weergave die verifieert dat de LEVEL <=CAPACITY. U kunt ook voorkomen dat de gegevens twee keer worden opgeslagen door de gerealiseerde weergave alleen gegevens te laten bevatten die de beperking zouden schenden. Dit vereist gematerialiseerde weergavelogboeken op beide basistabellen, wat een beetje overhead aan invoegingen zal toevoegen (hoewel minder dan het gebruik van triggers). Door de controle naar de commit-tijd te duwen, wordt het gelijktijdigheidsprobleem opgelost, maar het introduceert een beetje een uitzonderingsbeheerprobleem, omdat de COMMIT-bewerking nu kan mislukken omdat de gerealiseerde weergavevernieuwing is mislukt. Uw applicatie zou dat probleem moeten kunnen oplossen en de gebruiker op dat feit kunnen wijzen.
Optie 3:het gegevensmodel wijzigen
Als je een waarde in tabel A hebt die afhangt van een limiet in tabel B, kan dat erop wijzen dat de limiet in B een attribuut van tabel A zou moeten zijn (in plaats van of naast een attribuut van tabel B). Het hangt natuurlijk af van de specifieke kenmerken van uw datamodel, maar het is vaak het overwegen waard.