4) Jenže vybrat vhodný index nelze často bez znalosti statistiky uložených dat. Když mám například index nad cenou položky a jiný nad datem vložení a uživatel chce vyhledávat podle obou těchto kritérií, musí optimalizátor poznat, kde má začít, aby dotaz byl co nejefektivnější. A podobné je to přece u složitějších dotazů, které uživatel zadá třeba pomocí GUI nad více tabulkami. Optimální vyhledávací plán je závislý na filtrovacích a řadicích kritériích a pokud to databázový stroj nechá na programátorovi aplikace, programátor si bude muset napsat nějaký optimalizátor sám. To je jednoznačně krok zpět. Kdysi jsem díky nepříliš domyšlenému rozhodnutí pracoval na projektu, který začal jednoduchým modelem nad (dnes moderní) NoSQL databází, dospěli jsme k tomu, že jsme nad ní naimplementovali jednoduchý RDBMS a nakonec data skončila v klasické relační databázi. Nic proti podobným experimentům, v některých specifických doménách se může podobný přístup hodit. Ale obecně je to IMNSHO cesta do pekel.
Pokud použiju paralelu s "všeobecným programováním", ukládání mezivýsledků do lokálních proměnných funguje perfektně na jednoprocesorvých architekturách. Jakmile budu chtít výpočet škálovat a případně i distribuovat mezi více počítači, je mi klasický programovací model dost těsný a najednou se začne ukazovat, že deklarativní jazyky mají něco do sebe.
