Pár komentářů k DDL, které jste zveřejnili.
- Neexistuje žádný
AUTOINCREMENT
klíčové slovo v Oracle. Budete muset vytvořit sekvenci (obvykle jednu sekvenci na tabulku) a použítNEXTVAL
ze sekvence buď vINSERT
samotný příkaz nebo ve spouštěči k naplnění syntetického primárního klíče. - Neexistuje nic, co by vytvořilo
VENUE_NO
ve sloupciEVENT_DETAILS
. Předpokládám, že váš skutečný DDL definuje tento sloupec.
Toto nemůžete vynutit pomocí jednoduchého CHECK
omezení. Můžete vytvořit spouš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;
Uvědomte si však, že
- Také byste potřebovali mít spouštěč na
VENUE
tabulka, která kontroluje, zda změny kapacity místa nezpůsobí, že některé události se stanou neplatnými. Obecně by to vyžadovalo, aby v tabulce podrobností o události bylo nějaké datum, protože kapacita místa se pravděpodobně může v průběhu času měnit a vy opravdu chcete, aby ověření zkontrolovalo budoucí události v tomto místě. - Řešení založená na spouštění nebudou vždy fungovat v prostředích s více uživateli. Představte si, že místo 1 má kapacitu 30. Nyní relace A tuto kapacitu aktualizuje na 15. Ale než se relace A odevzdá, relace B vloží událost s
NO_PLAYERS
z 20. Žádný spouštěč relace nezaznamená problém, takže budou povoleny obě změny. Jakmile se však obě relace splní, bude událost rezervována pro 20 hráčů v místě, které podporuje pouze 15 hráčů. Spouštěč naEVENT_DETAILS
může potenciálně uzamknout řádek vVENUE
tabulky, abyste se vyhnuli tomuto sporu, ale serializujete vložky a aktualizace naEVENT_DETAILS
tabulka, což by mohl být problém s výkonem, zejména pokud vaše aplikace někdy čeká na lidský vstup před provedením transakce.
Jako alternativu ke spouštěčům můžete vytvořit ON COMMIT
materializovaný pohled, který spojí dvě tabulky dohromady a vloží CHECK
omezení na tento zhmotněný názor, který prosazuje požadavek, že počet hráčů nesmí překročit kapacitu hřiště. To bude fungovat ve víceuživatelském prostředí, ale vyžaduje to zhmotněné protokoly zobrazení na obou základních tabulkách a přesune to kontrolu do bodu, kdy se relace odevzdávají, což může být trochu složité. Většina aplikací nebere v úvahu možnost COMMIT
příkaz by mohl selhat, takže zpracování těchto výjimek může být složité. A z hlediska uživatelského rozhraní může být poněkud složité vysvětlit uživateli, v čem je problém, protože výjimka se může týkat změn provedených mnohem dříve v transakci.