Porównanie tej charakterystyki z cechami innych języków wysokiego poziomu wskazuje na wzajemne niedopasowanie tych klas języków. Konsekwencją tego stanu rzeczy jest powstanie różnych technik łączenia obu typów języków. Rozwój relacyjnych baz danych doprowadził do fenomenu tzw. zagnieżdżonego SQL (embedded), tzn. aplikacji tworzonych za pomocą języków wysokiego poziomu (Ada, C, Cobol, Fortran, Pascal, PL/1), w których bezpośrednio wykorzystuje się instrukcje SQL. Wymaga to dodatkowej fazy kompilacji programu źródłowego (prekompilacja) z uwagi na elementy SQL „nie znane" kompilatorowi bazowego języka programowania.

Możliwe jest wszakże tworzenie aplikacji z bazami typu relacyjnego o podobnie dużym stopniu integralności jak dla baz CODASYL-u, gdzie języki opisu i manipulacji danych: DDL (Data Description Language) i DML (Data Manipulation Language) oparto na COBOL-u. Metodą taką może być użycie języków 4GL bezpośrednio współpracujących z bazą danych. Języki 4GL, w jednej aplikacji, integrują graficzny system dialogowo-raportowy z bazą danych. Poziom tych narzędzi współcześnie pozwala na mówienie w tym kontekście raczej o systemach generowania aplikacji niż o językach, za pomocą których program jest „pisany”. Choć nie wszystko da się „wyczarować" kliknięciem myszki. Można również łączyć paradygmaty, korzystając z proceduralnego języka SQL (PL/SQL), który charakteryzują cechy:

• zastąpienie pojedynczych wywołań SQL do bazy danych (calls) strukturami blokowymi grupującymi komendy SQL, co poprawia wydajność konfiguracji

• bloki PL/SQL tłumaczone są na metakod DBMS, co umożliwia uniezależnienie oprogramowania od platformy hardware’owej

• możliwość hierarchicznego definiowania złożonych obiektów typu packages (dane + operacje na danych)

• deklaratywne możliwości programowania i zapewniania integralności danych (constraints)

• kursory (cursors): deklarowane w pamięci operacyjnej obszary zawierające rezultaty komend SQL, które mogą być przetwarzane podobnie jak zbiory sekwencyjne

• predefiniowana obsługa błędów wykonania (exception handling)

• implikacyjne (pośrednie) uaktywnianie obiektów programowych w zależności od stanu bazy danych (triggers).

Cechy te wynikają bezpośrednio z właściwości języków 3GL, niemniej owe niedogodności mogą być często uznane za drugorzędne z uwagi na możliwość korzystania z języków 3GL w otoczeniu bazy danych:

sterowanie urządzeniami we/wy odbywa się poza systemem bazy danych, na poziomie administracyjnym systemu operacyjnego lub na poziomie interfejsów użytkownika