Drugim typem rozwiązań ORM są takie, gdzie dla zadanej struktury relacyjnej generowane są obiekty, które po prostu upraszczają operacje bazodanowe. Co prawda programista nadal pracuje ze schematem relacyjnym, ale ta praca jest znacznie, znacznie prostsza. Chociażby dlatego, że wystarczy np. odwołać się do klucza obcego, by "automatycznie" móc pobrać dane z powiązanej tabeli.

Takim rozwiązaniem jest np. pakiet LLBLGen Pro, który pozwala generować taki zestaw obiektów dla różnych baz danych - SQL Server, Oracle, czy np. FireBird. Ten sposób pozwala programiście najpierw zbudować optymalny schemat danych, a potem wygenerować strukturę obiektową, która uprości mu dalszą pracę z kodem. Tak więc - podsumowując - dzięki ORM z punktu widzenia programu fakt, że jest to baza relacyjna może być w dużym stopniu "ukryty".

Wydaje się że bazy nierelacyjne będą stawać się rozwiązaniami coraz bardziej niszowymi, tym bardziej, że bazy relacyjne mają poważne atuty. Po pierwsze, koncepcja tabel jest bardzo czytelna dla każdego, kto pracował z dowolnym arkuszem kalkulacyjnym. Kolumny, warunki dla "filtrów" - wszystko to jest jasne i przejrzyste. Także narzędzia do raportowania (typu Crystal Reports) korzystają ze struktury relacyjnej.

Dodatkowo, za bazami relacyjnymi przemawia wieloletnie doświadczenie w optymalizacji zapytań i generalnie sztuka optymalnego pisania motorów bazodanowych. Nie bez znaczenia jest także spora ilość patentów w rękach Oracle/IBM/Microsoft. Być może w niektórych rozwiązaniach połączenie np. świata relacyjnego z obiektowym jest wyrazem braku technologicznej czystości lub toporności, ale na obecnym etapie działa ono całkiem sprawnie.

Jak najmniej zarządzania

Jeszcze kilka lat temu typowy motor bazodanowy nie potrafił np. w trakcie działania bazy wykonać defragmentacji tabel czy zaktualizować statystyk. Obecnie - cała sfera zarządzania bazami danych została zorganizowana w taki sposób, że te administracyjne operacje albo dzieją się automatycznie (baza "sama" dostraja się do danych warunków), albo mogą być wykonywane online. Pierwsza baza "samozarządzająca się" to chyba SQL Server 7.0. Teraz także Oracle, jak również IBM (DB2 8.2) dołączyły do swoich baz wiele mechanizmów, które upraszczają strojenie, a w wielu wypadkach je automatyzują.

Ale czy narzędzia administracyjne mają koniecznie być proste w użyciu? Microsoft wyraźnie tworzy coraz bardziej wyrafinowane (ale i proste) narzędzia dla administratorów. W SQL 2005 będą nawet dostępne dwa typy narzędzi GUI (zwykły i uproszczony, dla SQL Express). IBM nieznacznie modyfikuje swoje wcześniejsze narzędzia, wychodząc chyba z założenia, że i tak większość operacji administracyjnych to czynności powtarzalne, które można zapisać skryptem, a poza tym, administrator i tak musi biegle znać bazę, którą się opiekuje. Strategia IBM zasadza się na założeniu automatyzacji wewnętrznej - całkowicie bez udziału administratora. Oracle także próbuje oferować coraz prostsze narzędzia, ale należy tu podkreślić, że do tej bazy powstało dużo produktów firm trzecich, jak np. przeznaczone dla programisty OraTools czy SpotLight - narzędzia do monitowania. Sam Oracle oferuje (oddzielnie płatny) "zaawansowany" dodatek do zarządzania bazą w wersji 10g.