先訂清楚要判斷甚麼，再準備資料
共用場次的剩餘名額等於房間容量減已確認人數。此例容許略過人數太多的一組，按登記時間、再按編號找最早符合的一組。這是候補政策的選擇；嚴格先到先得可能必須等第一組，而不能直接跳過。
以下全部是假設資料。請在新的 SQLite 測試資料庫建立各表，再執行唯讀查詢。數量以件計，金額以港元的分作整數儲存；顯示港元時除以 100。
| 編號 | 預約編號 | 候補人數 | 登記時間 |
|---|---|---|---|
| W1 | B3 | 7 | 2026-10-08 09:00 |
| W2 | B3 | 2 | 2026-10-08 10:00 |
| W3 | B3 | 1 | 2026-10-08 11:00 |
CREATE TABLE rooms(id TEXT PRIMARY KEY, capacity INTEGER);
CREATE TABLE bookings(id TEXT PRIMARY KEY, room_id TEXT, starts_at TEXT, ends_at TEXT, seats INTEGER, status TEXT);
CREATE TABLE waitlist(id TEXT PRIMARY KEY, booking_id TEXT, requested_seats INTEGER, joined_at TEXT);
INSERT INTO rooms VALUES ('R1',8),('R2',4);
INSERT INTO bookings VALUES ('B1','R1','2026-10-10 09:00','2026-10-10 10:00',5,'confirmed'),('B2','R1','2026-10-10 09:30','2026-10-10 10:30',4,'confirmed'),('B3','R1','2026-10-10 10:30','2026-10-10 11:30',2,'confirmed'),('B4','R2','2026-10-10 12:00','2026-10-10 13:00',5,'confirmed'),('B5','R2','2026-10-10 12:00','2026-10-10 13:00',1,'cancelled');
INSERT INTO waitlist VALUES ('W1','B3',7,'2026-10-08 09:00'),('W2','B3',2,'2026-10-08 10:00'),('W3','B3',1,'2026-10-08 11:00');執行查詢，核對實際結果
SELECT w.id,w.requested_seats,r.capacity-b.seats AS free_seats
FROM waitlist w JOIN bookings b ON b.id=w.booking_id
JOIN rooms r ON r.id=b.room_id
WHERE b.id='B3' AND b.status='confirmed'
AND w.requested_seats<=r.capacity-b.seats
ORDER BY w.joined_at,w.id LIMIT 1;| 編號 | 候補人數 | 剩餘名額 |
|---|---|---|
| W2 | 2 | 6 |
B3 尚有 6 個位。W1 要 7 個，放不下；W2 要 2 個，是最早符合的一組；W3 也放得下，但較遲登記。查到 W2 只是建議，正式確認時仍要在同一次預約交易內重新查餘額。
按資料範圍使用結果
例子只建議一組，未計如何盡用座位，也未一次提拔多組。B3 在此是共用場次，與獨佔房間的衝突情境不同。查詢不會發出通知。
本例的建表、資料及結果已在 SQLite 執行。套用時先在系統測試副本調整欄位及狀態規則，再與流程負責人核對預期結果。其他資料庫平台未經測試。