Có ba cách cơ bản để giải quyết loại vấn đề này vì các ràng buộc CHECK không thể dựa trên một truy vấn.
Tùy chọn 1:Trình kích hoạt
Cách tiếp cận đơn giản nhất sẽ là đặt một kích hoạt trên TANK để truy vấn TANKS và ném một ngoại lệ nếu LEVEL vượt quá NĂNG LỰC. Tuy nhiên, vấn đề với kiểu tiếp cận đơn giản này là gần như không thể xử lý các vấn đề đồng thời một cách chính xác. Nếu phiên 1 giảm NĂNG LỰC, sau đó phiên 2 tăng MỨC, và sau đó cả hai giao dịch cam kết, trình kích hoạt sẽ không thể phát hiện vi phạm. Đây có thể không phải là vấn đề nếu một hoặc cả hai bảng hiếm khi được sửa đổi, nhưng nói chung đó sẽ là một vấn đề.
Tùy chọn 2:Chế độ xem cụ thể hóa
Bạn có thể giải quyết vấn đề đồng thời bằng cách tạo chế độ xem hiện thực hóa ON COMMIT tham gia bảng TANK và TANKS, sau đó tạo ràng buộc KIỂM TRA trên chế độ xem hiện thực hóa để xác minh rằng LEVEL <=CAPACITY. Bạn cũng có thể tránh lưu trữ dữ liệu hai lần bằng cách để chế độ xem cụ thể hóa chỉ chứa dữ liệu vi phạm ràng buộc. Điều này sẽ yêu cầu nhật ký chế độ xem cụ thể hóa trên cả hai bảng cơ sở, điều này sẽ thêm một chút chi phí để chèn (mặc dù ít hơn so với việc sử dụng trình kích hoạt). Đẩy kiểm tra đến thời gian cam kết sẽ giải quyết được vấn đề đồng thời nhưng nó gây ra một chút vấn đề về quản lý ngoại lệ vì thao tác COMMIT hiện có thể không thành công vì làm mới chế độ xem cụ thể hóa không thành công. Ứng dụng của bạn cần có khả năng xử lý vấn đề đó và cảnh báo cho người dùng về sự thật đó.
Tùy chọn 3:Thay đổi mô hình dữ liệu
Nếu bạn có một giá trị trong bảng A phụ thuộc vào một giới hạn trong bảng B, điều đó có thể chỉ ra rằng giới hạn trong bảng B phải là một thuộc tính của bảng A (thay vì hoặc thêm vào đó là một thuộc tính của bảng B). Tất nhiên, nó phụ thuộc vào các chi tiết cụ thể của mô hình dữ liệu của bạn, nhưng nó thường đáng được xem xét.
