SQL DROP TABLE for begyndere

DROP TABLE t1;

HVIS FINDER Klausul

Her er et eksempel på brug af IF EXISTS klausul for at kontrollere, om tabellen allerede eksisterer.

DROP TABLE IF EXISTS t1;

Brug af HVIS FINDER sikrer, at vi ikke får en fejl, hvis tabellen ikke eksisterer.

Her er, hvad der sker, hvis vi fjerner HVIS EKSISTERER fra erklæringen:

DROP TABLE t1;

Resultat:

Msg 3701, Level 11, State 5, Line 1
Cannot drop the table 't1', because it does not exist or you do not have permission.

Det er den besked, der returneres af SQL Server. Din besked vil afhænge af det DBMS, du bruger.

Afhængige fremmednøgler og visninger

Nogle RDBMS'er tillader en valgfri RESTRICT eller CASCADE nøgleord, der specificerer, hvad der sker, hvis tabellen har nogen fremmednøgler eller visninger, der refererer til den.

RESTRICT Mulighed

Her er et eksempel på brug af RESTRICT når du forsøger at slippe en tabel, der refereres til af en fremmednøgle i en anden tabel:

DROP TABLE t1 RESTRICT;

Resultat:

cannot drop table t1 because other objects depend on it

Dette eksempel blev udført ved hjælp af PostgreSQL. BEGRÆNSNING er standardindstillingen, så vi ville have modtaget det samme resultat, selvom vi ikke havde inkluderet RESTRICT søgeord.

CASCADE Mulighed

Her er, hvad der sker, hvis vi skifter til CASCADE når du forsøger at slippe den samme tabel (som refereres til af en fremmednøgle i en anden tabel):

DROP TABLE t1 CASCADE;

Resultat:

NOTICE:  drop cascades to constraint t2_c2_fkey on table t2
Commands completed successfully

Dette droppede den fremmednøgle, der refererede til vores t1 bord. Fremmednøglen hed t2_c2_fkey .

Bemærk, at det ikke tabte bordet, der havde fremmednøglen. Det tabte kun den fremmede nøgle.

Hvis måltabellen (t1 ) blev refereret af alle visninger, ville hele visningen være blevet slettet.

Du behøver ikke at angive CASCADE for at slette eventuelle indekser, regler, triggere eller begrænsninger, der findes for måltabellen. Disse slettes automatisk, selv når du bruger standardindstillingen (RESTRICT ).

MySQL og MariaDB

Nogle DBMS'er (såsom MySQL og MariaDB) accepterer RESTRICT og CASCADE søgeord, men de gør ikke noget. De er tilvejebragt ganske enkelt for lettere overførsel mellem DBMS'er.

Oracle

Oracle har en lidt anderledes syntaks, CASCADE CONSTRAINTS , som fjerner alle referenceintegritetsbegrænsninger, der refererer til primære og unikke nøgler i den tabte tabel.

SQL-server

SQL Server understøtter ikke CASCADE eller RESTRICT søgeord. Hvis tabellen har nogen fremmednøgleafhængigheder, skal du slette dem, før du slipper tabellen, ellers får du en fejl.

I SQL Server kan du dog droppe en tabel, selvom den er refereret af en visning eller en lagret procedure. Derfor bør du tjekke for sådanne referencer og udtrykkeligt droppe dem ved at bruge DROP VIEW eller DROP PROCEDURE .

SQLite

SQLite understøtter ikke CASCADE eller RESTRICT søgeord.

Hvis måltabellen refereres af nogen visninger, vil tabellen stadig blive slettet (og visningen forbliver).

Hvis måltabellen refereres af nogen fremmednøgler, vil resultatet afhænge af, om du har fremmednøgler aktiveret, og hvis det er tilfældet, om der er nogen data i den underordnede tabel, og hvis det er tilfældet, om fremmednøglen er defineret med PÅ SLET CASCADE .

Hvis du bruger SQLite, se SQLite DROP TABLE for et eksempel og diskussion om at droppe en tabel, der refereres til af en fremmednøgle.

Slip flere tabeller

Nogle RDBMS'er tillader dig at droppe flere tabeller fra en enkelt DROP TABLE erklæring.

Eksempel:

DROP TABLE t11, t12;

RDBMS'erne, der understøtter denne syntaks, inkluderer SQL Server, MySQL, MariaDB og PostgreSQL.

Men hvis du sletter en tabel, der refereres til af en fremmednøgle, og den fremmednøgle forhindrer den i at blive slettet, skal du angive den underordnede tabel før den overordnede tabel.

For eksempel, hvis jeg kører ovenstående sætning i SQL Server, får jeg følgende fejl:

Msg 3726, Level 16, State 1, Line 1
Could not drop object 't11' because it is referenced by a FOREIGN KEY constraint.

I dette tilfælde kan jeg simpelthen ændre rækkefølgen af ​​tabellerne i min DROP TABLE erklæring:

DROP TABLE t12, t11;

Faktisk, i dette tilfælde, fik jeg en anden fejl, der fortalte mig, at t12 eksisterer ikke.

Her er hvad jeg fik:

Msg 3701, Level 11, State 5, Line 1
Cannot drop the table 't12', because it does not exist or you do not have permission.

Dette er fordi, selvom den forrige sætning ikke kunne slippe t11 , det lykkedes faktisk at droppe t12 .

Og ligesom en komedie af fejl, var den denne gang i stand til at slippe t11 men ikke t12 .

Uanset hvad er begge borde nu blevet droppet.

Men hvis du får ordren korrekt første gang, skulle du modtage en besked som denne:

Commands completed successfully.

Det MIDLERTIDIGE søgeord

Nogle RDBMS'er (såsom MySQL og MariaDB) accepterer en MIDDELIGE søgeord.

Det går mellem DROP og TABEL , sådan her:

DROP TEMPORARY TABLE t1;

Brug af MIDDELIGE søgeord sikrer, at du ikke ved et uheld taber en ikke-midlertidig tabel, når du forsøger at slippe en midlertidig tabel.

Den MIDDELIGE søgeord har følgende effekter:

• Sætningen falder kun MIDDELSIG tabeller.
• Sætningen forårsager ikke en implicit commit (ved hjælp af DROP TABLE uden den MIDDELIGE søgeord begår automatisk den aktuelle aktive transaktion).
• Ingen adgangsrettigheder er markeret. En MIDLERTIDIG tabellen er kun synlig med den session, der oprettede den, så ingen kontrol er nødvendig.