Điều này có khả thi trong Oracle / Sql không?

Một vài nhận xét về DDL bạn đã đăng.

• Không có AUTOINCREMENT từ khóa trong Oracle. Bạn cần tạo một chuỗi (thường là một chuỗi cho mỗi bảng) và sử dụng NEXTVAL từ trình tự trong INSERT chính câu lệnh đó hoặc trong một trình kích hoạt để điền khóa chính tổng hợp.
• Không có gì đang tạo VENUE_NO trong EVENT_DETAILS . Tôi cho rằng DDL thực tế của bạn đang xác định cột đó.

Bạn không thể thực thi điều này thông qua một CHECK đơn giản hạn chế. Bạn có thể tạo trình kích hoạt

CREATE OR REPLACE TRIGGER validate_capacity
  BEFORE INSERT OR UPDATE ON event_details
  FOR EACH ROW
DECLARE
  l_venue_capacity venue.capacity%type;
BEGIN
  SELECT capacity
    INTO l_venue_capacity
    FROM venue
   WHERE venue_no = :new.venue_no;

  IF( l_venue_capacity < :new.no_players )
  THEN
    RAISE_APPLICATION_ERROR( -20001, 'Sorry, the venue has insufficient capacity' );
  END IF;
END;

Tuy nhiên, hãy lưu ý rằng

• Bạn cũng cần có một trình kích hoạt trên VENUE bảng kiểm tra xem liệu những thay đổi đối với sức chứa của địa điểm có làm cho một số sự kiện trở nên không hợp lệ hay không. Nói chung, điều đó sẽ yêu cầu phải có một số loại ngày trong bảng chi tiết sự kiện vì có lẽ, sức chứa của một địa điểm có thể thay đổi theo thời gian và bạn thực sự chỉ muốn xác thực để kiểm tra các sự kiện trong tương lai tại địa điểm đó.
• Các giải pháp dựa trên trình kích hoạt không phải lúc nào cũng hoạt động trong môi trường nhiều người dùng. Hãy tưởng tượng địa điểm 1 có sức chứa là 30. Bây giờ, phiên A cập nhật sức chứa đó lên 15. Nhưng trước khi phiên A cam kết, phiên B sẽ chèn một sự kiện với NO_PLAYERS của 20. Cả hai trình kích hoạt của phiên sẽ không gặp sự cố vì vậy cả hai thay đổi sẽ được cho phép. Nhưng sau khi cả hai phiên cam kết, sẽ có một sự kiện được đặt trước với 20 người chơi tại một địa điểm chỉ hỗ trợ 15 người chơi. Trình kích hoạt trên EVENT_DETAILS có khả năng khóa hàng trong VENUE để tránh điều kiện cuộc đua này nhưng chúng bạn đang tuần tự hóa các phụ trang và cập nhật trên EVENT_DETAILS bảng này có thể là một vấn đề về hiệu suất, đặc biệt nếu ứng dụng của bạn đợi con người nhập liệu trước khi thực hiện giao dịch.

Để thay thế cho trình kích hoạt, bạn có thể tạo ON COMMIT dạng xem vật chất hóa nối hai bảng với nhau và đặt một CHECK hạn chế về quan điểm cụ thể hóa đó nhằm thực thi yêu cầu số lượng người chơi không được vượt quá sức chứa của địa điểm. Điều đó sẽ hoạt động trong môi trường nhiều người dùng nhưng nó yêu cầu nhật ký chế độ xem cụ thể hóa trên cả hai bảng cơ sở và nó di chuyển việc kiểm tra đến điểm mà các phiên cam kết có thể hơi phức tạp. Hầu hết các ứng dụng không xem xét khả năng COMMIT câu lệnh có thể bị lỗi vì vậy việc xử lý những ngoại lệ đó có thể khó khăn. Và từ quan điểm giao diện người dùng, có thể hơi khó giải thích cho người dùng hiểu vấn đề là gì vì ngoại lệ có thể liên quan đến những thay đổi được thực hiện trước đó nhiều trong giao dịch.