Een externe-sleutelbeperking afdwingen voor kolommen van dezelfde tabel

Oracle noemt dit een zelfreferentiële integriteitsbeperking. De documentatie is hier voor een beschrijving,

U creëert een zelfreferentiële beperking op dezelfde manier als een normale beperking:

alter table employees
  add constraint employees_emp_man_fk
      foreign key ( manager_no )
      references employees ( emp_id )
   on delete set null
      ;

Ik neem aan dat je manager_no is nulleerbaar. Ik heb set null hier toegevoegd als een delete cascade zou waarschijnlijk een aanzienlijk deel van uw tafel wegvagen.

Ik kan geen betere manier bedenken om dit te doen. Het verwijderen van een manager mag niet resulteren in de verwijdering van al hun werknemers, dus u moet set null en een trigger op tafel hebben om u te waarschuwen voor iemand zonder manager.

Ik vind deze site altijd leuk, wat goed is voor eenvoudige referenties. en vergeet niet om ook een index op de FK te hebben of Tom zal tegen je schreeuwen :-).

Men kan ook de standaard Oracle-syntaxis gebruiken om een ​​naar zichzelf verwijzende FK te creëren in de create table-instructie, die er als volgt uit zou zien.

create table employees
 ( emp_id number
 , other_columns ...
 , manager_no number
 , constraint employees_pk 
    primary key (emp_id)
 , constraint employees_man_emp_fk
    foreign key ( manager_no )
    references employees ( emp_id )
    on delete set null
 );

BEWERKEN:

In antwoord op de opmerking van @popstack hieronder:

Hoewel je dit in één verklaring kunt doen, is het een vrij belachelijke stand van zaken om een ​​tafel niet te kunnen wijzigen. Je moet zeker een tabel analyseren waaruit je gaat selecteren en je wilt nog steeds een index op de refererende sleutel (en mogelijk meer kolommen en/of meer indexen), anders wanneer je de refererende sleutel gebruikt die je gaat doen een volledige tafelscan. Zie mijn link naar asktom hierboven.

Als u een tabel niet kunt wijzigen, moet u dit doen, in afnemende volgorde van belangrijkheid.

1. Ontdek hoe u dat kunt doen.
2. Verander je DB-ontwerp aangezien een FK een index zou moeten hebben en als je er geen kunt hebben, dan zijn FK's waarschijnlijk niet de juiste keuze. Misschien een tabel met managers en een tabel met werknemers?