Jak jsem psal výše, mě zajímají principy. To, že aktuální ORM nejsou ve stavu, kdy by to všechno fungovalo krásně out-of-the-box, to je mi jasné, uvědomuji si to, a uznávám. Ale považuji to za otázku vývoje, nikoliv za principielní problém. Ano, já si pamatuju dobu, kdy to lidem stálo za to a v Delphi psali pasáže v asm.
Takže děkuji za jakékoliv příspěvky, které popisují principielní potíže, se kterými se musí ono ORM vypořádat.
Ta principiální potíž je v tom, že RDBMS jsou výkonné právě a tehdy, kdy jsou správně nastavené tabule, constrainty, klíče, vzdálené klíče, indexy, ..., a především, když je možné maximum rozhodovacích mechanismů přenést do DB. Interné optimalizátor dotazu se pak těchto informací může chytit a snažit se je využít k vymyšlení nejlepšího postupu pro získání / zápis dat.
Tedy např. když vím, že chci přebarvit všechna auta na červenou, vyjma zelených aut vyrobených v roce 2009, pak potřebuju, aby databáze měla takovou strukturu, aby se k diskriminantům dostala rychle. Musí umět rychle vyhodnotit, jestli nejdřív vybere auta vyrobená <> 2009 a pak s barvou <> zelenou, nebo jestli bude rychlejší opačný postup. Nebo jestli bude nejrychlejší projít všechna auta po sobě, a těch pár, které jsou zelené a vyrobené v 2009 přeskočit (tj. indexy, statistiky, složené indexy, ...).
Můžete mít také auta, u kterých nevíte rok výroby nebo nevíte barvu. ORM za Vás nerozhodne, jestli může (má) použít inner nebo outer join. V prostém případě to nebude mít na výkon velký vliv, ale pokud půjde o složený dotaz se subselecty, bude inner/outer hrát roli v tom, co dokáže optimalizátor ze subselectu vyčlenit nad něj, a co ne.
O tom, jak dotaz realizovat, musí přemýšlet i ten, kdo pracuje přímo v SQL, a nezřídka se stává, že váhá. Zejména, když sestavujete view, tak očekáváte, že bude použito v dalším složeném dotazu. Když view navrhnete špatně, tak může dávat při prostém selectu data rychle, ale může být pro optimalizátor už dále neoptimalizovatelné v dalších složených dotazech. Někdy se vyplatí, pokud víte, co se s tím bude dál dít, napsat view složitěji, ale optimalizovatelněji.
Toto všechno neumí vyřešit RDBMS, a programátor v SQL se s tím taky zapotí. Proto tvrdím, že není reálné očekávat, že ORM by i někdy v budoucnu toto uměly.
Dál mě k tomu přesvědčení vede i to, že optimalizace se musí provádět co nejblíž k datům. RDBMS jsou výkonné jen a právě díky tomu. Dovedu si představit ORM, které by nějakou svojí inteligencí přenášelo nadefinované objekty do dobře vytvořených SQL definic. Jenže to to ORM nebude schopné vymyslet samo, musí to vyčíst z definic poskytnutých programátorem. Tyto definice v rámci ORM by tedy musely být na tolik přesné, aby je šlo 1:1 přenést do DB. Pokud by ty definice měly být na tolik přesné - pak už ORM nebude šetřit práci, pouze bude jinou mluvou definovat totéž.
Mám takový pocit, že hledáte potvrzení, že nějaká ORM mechanika dokáže vymyslet to, co nikdo za desítky let nevymyslel ani v rámci RDBMS.