Perché alcuni DBMS non consentono il rollback per determinate istruzioni DDL?

Recentemente ho scoperto che MySQL non supporta il rollback di DDL come "alter table" ... Essere abituato a PostgreSQL, che mi ha sembrato strano, ma un mio amico mi ha detto che anche Oracle non lo consente. Ci sono ragioni tecniche per non supportarlo? È semplicemente una caratteristica "poco interessante" per loro?

Modifica: ho appena trovato questo confronto . Sembra che ci sono molti DBMS che fanno sostegno DDL transazionale.

Il motivo per cui questo funziona in PostgreSQL è che i cataloghi di sistema sono tabelle regolari. Pertanto, la creazione di una nuova funzione, ad esempio, richiede solo l'inserimento di una riga nella pg_proctabella, la modifica del valore predefinito di una colonna richiede solo l'aggiornamento di alcune righe pg_attrdefe così via. Dato che le tabelle sono comunque transazionali, dovresti quasi fare di tutto per non farlo funzionare in quel modo. (Molti dettagli di implementazione dolorosi sono stati omessi qui. ;-))

Suppongo, non conoscendo il codice sorgente, che altri motori di database utilizzino alcune strutture interne personalizzate per rappresentare le informazioni del loro catalogo di sistema. E quindi dovrebbero fare uno sforzo extra, probabilmente uno sforzo extra, per far funzionare il DDL transazionale, e apparentemente non è una priorità per loro.

Il rovescio della medaglia è che questo è il motivo per cui gli aggiornamenti delle versioni principali di PostgreSQL sono così dolorosi. Altri prodotti possono presumibilmente progettare le loro strutture di metadati interne tenendo conto delle modifiche e degli aggiornamenti, e quindi non ci sono problemi con l'aggiornamento a una nuova versione principale. In PostgreSQL, non c'è modo di cambiare una tabella del catalogo di sistema in modo che appaia improvvisamente come una versione più recente di una tabella del catalogo di sistema, almeno non mantenendo il sistema online, poiché ciò richiederebbe l'accesso ai cataloghi di sistema. Urgh.

La maggior parte no? Bummer.

Uso principalmente SQL Server e lo fa. So che Oracle no, ma pensavo che Oracle potesse essere un'aberrazione.

In SQL Server, sono abbastanza certo che puoi eseguire più istruzioni DDL in una singola transazione anche se penso anche che ci siano un paio di restrizioni (che ho dimenticato tutte). Puoi fare una creazione o una modifica o una goccia della maggior parte delle cose e ripristinarla, se lo desideri. Red-Gate SQL Compare (uno strumento che adoro) ne approfitta.

Il problema è che l'ambito della transazione diventa abbastanza interessante ... Quando coinvolgi i cataloghi di sistema in una transazione di aggiornamento (DDL), corri il rischio di prendere alcuni blocchi davvero importanti e potresti bloccare l'accesso ai cataloghi di sistema. Gli utenti non possono fare molto se le loro query non riescono a trovare le loro tabelle nei cataloghi!

A conti fatti, tuttavia, è utile poter includere DDL in una transazione con più estratti conto.

Più utile, il comando DDL di SQL Server TRUNCATE può anche essere un elemento di una transazione con più istruzioni . Puoi troncare una tabella di destinazione (molto velocemente), crearla e quindi eseguire un commit se ti piace il risultato. Se qualcosa va storto, rollback e voilà !, è come se non avessi mai disturbato il tavolo. Anche lo spazio del registro è ridotto al minimo. Ne approfitto abbastanza spesso.

In SQL Server possiamo eseguire il rollback delle istruzioni DDL, non utilizza il commit automatico alla fine dell'istruzione. In altri DBMS non lo so, ma ricordo che in Oracle non si può fare lo stesso. Credo che sia specifico per ogni DBMS, non sono sicuro di cosa direbbe lo standard SQL a riguardo, ma sono sicuro che nessun produttore implementa il 100% dello standard.

C'è una domanda simile su SO: è possibile eseguire più istruzioni DDL all'interno di una transazione (all'interno di SQL Server)?

Oracle ha condiviso l'analisi delle query, quindi un SELECT * FROM table_a eseguito da una sessione è (normalmente) uguale a quello di un'altra sessione. Ciò si spezzerebbe se una sessione pensasse che ci fossero dieci colonne nella tabella e un'altra pensasse che ce ne fossero undici.