sql >> Databáze >  >> RDS >> Oracle

Je to možné v Oracle/Sql?

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žít NEXTVAL ze sekvence buď v INSERT 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 sloupci EVENT_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ěč na EVENT_DETAILS může potenciálně uzamknout řádek v VENUE tabulky, abyste se vyhnuli tomuto sporu, ale serializujete vložky a aktualizace na EVENT_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.




  1. Postgres se po spuštění s docker-compose okamžitě vypne

  2. Příkaz MySQL Vysvětlete ignorovat LIMIT?

  3. Postgresql JSONB se blíží. Co použít nyní? Hstore? JSON? EAV?

  4. Jak mohu aktualizovat pole mého číselníku pomocí uživatelského vstupu v EditText