Pár komentářů k DDL, které jste zveřejnili.
- Neexistuje žádný
AUTOINCREMENTklíčové slovo v Oracle. Budete muset vytvořit sekvenci (obvykle jednu sekvenci na tabulku) a použítNEXTVALze sekvence buď vINSERTsamotný příkaz nebo ve spouštěči k naplnění syntetického primárního klíče. - Neexistuje nic, co by vytvořilo
VENUE_NOve 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
VENUEtabulka, 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_PLAYERSz 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_DETAILSmůže potenciálně uzamknout řádek vVENUEtabulky, abyste se vyhnuli tomuto sporu, ale serializujete vložky a aktualizace naEVENT_DETAILStabulka, 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.