Na początek niektóre standardowe funkcje Oracle wykorzystują typy, na przykład XMLDB i Spatial (które obejmują deklarowanie kolumn typów danych Nested Table).
Ponadto wielu programistów PL/SQL używa typów przez cały czas, do deklarowania kolekcji PL/SQL lub funkcji potokowych.
Ale zgadzam się, że kilka miejsc intensywnie używa typów i buduje z nich API PL/SQL. Istnieje kilka powodów takiego stanu rzeczy.
- Oracle bardzo powoli wdrażała Obiekty. Chociaż zostały wprowadzone w wersji 8.0, dopiero w wersji 9.2 w pełni wspierały dziedziczenie, polimorfizm i konstruktory zdefiniowane przez użytkownika. Właściwe programowanie obiektowe jest niemożliwe bez tych funkcji. Nie otrzymaliśmy
SUPER()
do wersji 11g. Nawet teraz brakuje funkcji, w szczególności prywatnych deklaracji w TYPE BODY. - Składnia jest często niezgrabna lub frustrująco niejasna. Dokumentacja nie pomaga.
- Większość osób pracujących z Oracle wywodzi się z relacyjnej/proceduralnej szkoły programowania. Oznacza to, że zwykle nie rozumieją OOP lub nie rozumieją, gdzie może to być przydatne w programowaniu baz danych. Nawet jeśli ludzie wpadną na fajny pomysł, ich wdrożenie przy użyciu składni Oracle jest trudne lub niemożliwe.
Ten ostatni punkt jest kluczowy. Możemy nauczyć się nowej składni, możemy nakłonić Oracle do uzupełnienia zestawu funkcji, ale warto to robić tylko wtedy, gdy potrafimy wymyślić zastosowanie typów. Oznacza to, że potrzebujemy problemów, które można rozwiązać za pomocą dziedziczenia i polimorfizmu.
Pracowałem nad jednym systemem, który intensywnie wykorzystywał typy. Był to system hurtowni danych, a podsystem ładowania danych zbudowany był z typów. Podstawowe uzasadnienie było proste:
- musimy zastosować ten sam szablon reguł biznesowych dla każdej ładowanej tabeli, więc proces jest ogólny;
- każda tabela ma swoją własną projekcję, więc instrukcje SQL są dla każdej z nich niepowtarzalne.
Implementacja typu jest czysta:ogólny proces jest zdefiniowany w typie; implementacja dla każdej tabeli jest zdefiniowana w Type, który dziedziczy z tego typu ogólnego. Określone typy można generować z metadanych. Przedstawiłem ten temat na UKOUG kilka lat temu, a dokładniej opisałem go na swoim blogu.Dowiedz się więcej.
Nawiasem mówiąc, teoria relacyjna obejmuje koncepcję domen, które są typami danych zdefiniowanymi przez użytkownika, w tym ograniczeniami itp. Żaden smak RDBMS nie obsługuje domen, ale implementacja typów Oracle jest zdecydowanie krokiem na tej drodze.