Dlaczego niektóre DBMS nie pozwalają na wycofanie niektórych instrukcji DDL?

Niedawno dowiedziałem się, że MySQL nie obsługuje wycofywania DDL, takich jak „alter table” ... Przyzwyczajony do PostgreSQL, co wydało mi się dziwne, ale mój przyjaciel powiedział mi, że nawet Oracle nie pozwala na to. Czy istnieją techniczne powody, aby go nie obsługiwać? Czy jest to dla nich po prostu „nieciekawa” funkcja?

Edycja: właśnie znalazłem to porównanie . Wygląda na to, że istnieje wiele DBMS, które obsługują transakcyjny DDL.

Powodem, dla którego działa to w PostgreSQL, jest to, że katalogi systemowe są zwykłymi tabelami. Tak więc na przykład utworzenie nowej funkcji wymaga tylko wstawienia wiersza do pg_proctabeli, zmiana domyślnej wartości kolumny wymaga jedynie aktualizacji niektórych wierszy pg_attrdefi tak dalej. Ponieważ tabele i tak są transakcyjne, prawie musisz zejść z siebie, aby nie działały w ten sposób. (Wiele bolesnych szczegółów implementacji pominięto tutaj ;-))

Podejrzewam, że nie znając kodu źródłowego, inne silniki baz danych używają niestandardowych struktur wewnętrznych do reprezentowania informacji z katalogu systemowego. Musieliby więc włożyć dodatkowy wysiłek, prawdopodobnie duży wysiłek, aby transakcyjny DDL działał i najwyraźniej nie jest to dla nich priorytetem.

Wadą tego jest to, że główne aktualizacje PostgreSQL są tak bolesne. Inne produkty mogą prawdopodobnie projektować swoje wewnętrzne struktury metadanych z myślą o zmianach i aktualizacjach, więc nie ma problemów z aktualizacją do nowej głównej wersji. W PostgreSQL nie ma możliwości zmiany tabeli katalogu systemowego, aby nagle wyglądała jak nowsza wersja tabeli katalogu systemowego, przynajmniej nie podczas utrzymywania systemu w trybie online, ponieważ wymagałoby to dostępu do katalogów systemowych. Urgh.

Większość nie? Bummer.

Używam głównie SQL Server i tak się dzieje. Wiem, że Oracle nie, ale myślałem, że może to być aberracja.

W SQL Server jestem pewien, że możesz uruchomić wiele instrukcji DDL w jednej transakcji, chociaż uważam również, że istnieje kilka ograniczeń (o których wszyscy zapomniałem). Możesz stworzyć lub zmienić lub upuścić większość rzeczy i cofnąć, jeśli chcesz. Red-Gate SQL Compare (narzędzie, które kocham) korzysta z tego.

Problem polega na tym, że zakres transakcji staje się dość interesujący ... Gdy zaangażujesz katalogi systemowe w transakcję aktualizacji (DDL), ryzykujesz podjęcie naprawdę ważnych blokad i możesz zablokować dostęp do katalogów systemowych. Użytkownicy nie mogą wiele zrobić, jeśli ich zapytania nie mogą znaleźć tabel w katalogach!

Podsumowując, przydatne jest włączenie DDL do transakcji zawierającej wiele wyciągów.

Bardziej użyteczne polecenie SQL Server DDL TRUNCATE może być również elementem transakcji zawierającej wiele wyciągów . Możesz obciąć tabelę docelową (bardzo szybko), zbudować ją, a następnie wykonać zatwierdzenie, jeśli podoba ci się wynik. Jeśli coś pójdzie nie tak, wycofujesz się i voila !, to tak, jakbyś nigdy nie zakłócał stołu. Przestrzeń dziennika jest również zminimalizowana. Korzystam z tego dość często.

W SQL Server możemy wycofać instrukcje DDL, nie używa automatycznego zatwierdzania na końcu instrukcji. W innych DBMS nie wiem, ale pamiętam, że w Oracle nie można zrobić tego samego. Uważam, że jest specyficzny dla każdego DBMS, nie jestem pewien, co powiedziałby na ten temat standard SQL, ale jestem pewien, że żaden producent nie implementuje 100% standardu.

Podobne pytanie dotyczy SO: Czy można uruchomić wiele instrukcji DDL w ramach transakcji (w programie SQL Server)?

Oracle współużytkuje parsowanie zapytań, więc WYBIERZ * Z table_a wykonany przez jedną sesję jest (zwykle) taki sam jak w innej sesji. To by się załamało, gdyby jedna sesja myślała, że ​​w tabeli jest dziesięć kolumn, a inna, że ​​jedenaście.