Ta výhoda spočívá v tom, že ty datové funkce jsou primitivní (rychleji už to nejde) a mají očekávanou odezvu, ať už jsou nasazeny v aplikačním programu kdekoliv. Programátor postupuje tedy tak, že vytváří primitivní aplikační funkce (kdy každá z nich si může obstarat potřebná data s max. možnou rychlostí), které kombinuje do komplexnějších celků. Změna v aplikaci se provádí záměnou jednoduchých aplikačních funkcí -říkejme tomu modularita.
Tipoval bych, že Vám ani nevadí relační model, jako SQL. Existovaly knihovny, kde se i s relačními databázemi pracovalo podobně - v 90 letech existovalo několik knihoven, minimálně jedna od Borlandu, a co jsem se díval, tak na GitHubu jsou desítky. Tohle je věčná diskuze trvající od konce éry COBOLu, a argumenty jedné i druhé strany jsou stejné. Doporučoval bych diskuzi, obhajobu SQL od Joe Celka (což je dneska už pán v letech, který hodně hezky popsal přechod od COBOLu k SQL).
S SQL určitě ztrácíte nad procesem zpracování dat kontrolu, což pro některé vývojáře může být nepříjemné. Podobně jako je pro mne např. nepříjemné použití ORM. Zas těch přecitlivělých vývojářů je relativně málo, což dokazuje rozšíření SQL i ORM. Určitě s použitím generické databáze ztrácíte v limitních případech až řád výkonu - zvlášť pokud dokážete efektivně využít paměť - což není o SQL, ale o tom, že se používá obecné uložiště a neustále se musí mapovat na zadaný záznam, který ale není zadrátovaný do kódu.
Na stranu druhou - tento hard code přístup měl hodně strmou křivku učení, což nemuselo být zřejmé před 40 lety, kdy nebyly alternativy, a bez programátorů jste se k datům nedostal, což zase omezovalo práci s daty a prodlužovalo reálný čas dostupnosti databáze. Tehdejší databáze byly relativně efektivní (na tehdejším HW), ale musel jste počkat 2-3 dny, možná týden, než Vám programátor napsal report. To je jeden z důvodů proč vzniklo SQL - efektivitu nikdo až tak moc neřešil, ale uživatelé přes terminál mohli mít data během několika minut.
Navíc i ty staré relační databáze některé úlohy z principu řešily lépe než staré síťové - a ve chvíli, kdy šla CPU výkonnostně nahoru (90 léta), tak ten direktivní přístup k datům ztratil význam. Za posledních deset let jsem u dvou uživatelů Postgresu konstatoval, že by to měli přepsat do Cčka, a databázi použít jen jako storage nebo nepoužít. Ono to SQL funguje docela hezky.