Ada tiga cara dasar untuk memecahkan masalah semacam ini karena batasan CHECK tidak dapat didasarkan pada kueri.
Opsi 1:Pemicu
Pendekatan yang paling sederhana adalah dengan menempatkan pemicu pada TANK yang menanyakan TANKS dan memberikan pengecualian jika LEVEL melebihi KAPASITAS. Masalah dengan pendekatan sederhana semacam ini, adalah hampir tidak mungkin untuk menangani masalah konkurensi dengan benar. Jika sesi 1 menurunkan KAPASITAS, maka sesi 2 meningkatkan LEVEL, dan kemudian kedua transaksi melakukan, pemicu tidak akan dapat mendeteksi pelanggaran. Ini mungkin tidak menjadi masalah jika salah satu atau kedua tabel jarang diubah, tetapi secara umum akan menjadi masalah.
Opsi 2:Tampilan terwujud
Anda dapat memecahkan masalah konkurensi dengan membuat tampilan terwujud ON COMMIT yang menggabungkan tabel TANK dan TANK dan kemudian membuat batasan PERIKSA pada tampilan terwujud yang memverifikasi bahwa LEVEL <=CAPACITY. Anda juga dapat menghindari penyimpanan data dua kali dengan membuat tampilan terwujud hanya berisi data yang akan melanggar batasan. Ini akan membutuhkan log tampilan yang terwujud pada kedua tabel dasar yang akan menambahkan sedikit overhead ke sisipan (meskipun lebih sedikit daripada menggunakan pemicu). Mendorong cek ke waktu komit akan menyelesaikan masalah konkurensi tetapi ini menimbulkan sedikit masalah manajemen pengecualian karena operasi COMMIT sekarang dapat gagal karena penyegaran tampilan yang terwujud gagal. Aplikasi Anda harus mampu menangani masalah itu dan mengingatkan pengguna akan fakta itu.
Opsi 3:Ubah model data
Jika Anda memiliki nilai dalam tabel A yang bergantung pada limit dalam tabel B, itu mungkin menunjukkan bahwa limit dalam B seharusnya merupakan atribut dari tabel A (bukan atau sebagai tambahan menjadi atribut dari tabel B). Itu tergantung pada spesifikasi model data Anda, tentu saja, tetapi sering kali patut dipertimbangkan.
