Vlákno názorů k článku Na co si dát pozor při návrhu databáze? od pb. - Tenhle článek jsem potřeboval před dvaceti lety. Takhle...

Tenhle článek jsem potřeboval před dvaceti lety. Takhle se můžu jenom pousmát a vzpomenout si, jak jsem byl kdysi nezkušený a blbý = cítil jsem se jako génius (entity-atribute-value - EAV a výsledné dotazy vypadají impozantně a mnohem geniálněji, než poloprázdná tabulka). Otázka je, jestli bych před těmi dvaceti lety článku rozuměl a dokázal se podle toho zařídit. Vždyť EAV vypadá tak sofistikovaně, hodné mého génia - ego je strašná věc.

V létě jsem měl malinký konflikt s jedním mladým zaměstnancem. Zabudoval do jedné drobné, již fungující aplikace vlastní jednoduchou obdobu ORM. S kolegou jsme mu to opatrně rozmluvili a celé jeho ORM zrušili. Ale dodnes mám podezření, že nám stejně neuvěřil. ON by to ukočíroval - ego je strašna věc.

Myslím, že na konstrukce uvedené v článku budete narážet až do konce života.

Tak ORM bylo, nebo asi ještě i je, velmi v módě. Někde má smysl, resp. dobře se s tím pracuje a výkon nijak netrpí, obzvláště v kombinaci s cache jak na straně aplikace, tak na straně databáze, lazy loadingem atd . . . V tom je právě asi to, o čem jsi psal, že nějaká větší optimalizace má smysl až od určité úrovně, resp. složitosti nebo množství (krom obecně platných principů a smysluplných věcí).
A to z Vás ani nikdo nevzpomenul, ale záleží také na tipu databáze a na jazyku, použitém pro systém, ale taky na účelu, protože jinak budeš psát třeba aplikaci, kde záleží na nejakém frontu na každé milisekundě * počet návštěvníků a jinak když je to jedno, hlavně aby programátor co nejrychleji namlátil vypisy složitě souvisejících dat do 15 -30 stránek za týden, nebo to často měnil po malých objememech . . .

S ORM jsem se nikdy nezkamarádil. V mém případě (kolega je na tom stejně) to obvykle vedlo právě k různým děsům v databázové vrstvě, takže část aplikace dělala "někde něco" uvnitř bez rozumné možnosti to ovlivnit a část aplikace byla pracně přepsaná z ORM na optimalizované dotazy. Než mít v jedné aplikaci dva různé přístupy k jedné věci, přijde mi vhodnější to sjednotit.

To byl i důvod, proč se mi nelíbilo ORM vymyšlené kolegou v naší aplikaci. Jednodušší část, se kterou si kolega poradil, byla z jednoduchých selektů přepsaná do jednoduchých mapových struktur (které si musel každý nový příchozí nastudovat a pochopit) a složitá část zůstala ve složitých SQL dotazech.

Jasně. A to je právě to. Klidně můžeš mít na 90% aplikace výpisy relačních dat, na které se to hezky hodí a můžeš sekat třeba templates "jak Baťa cvičky" a pak, u 5~ % udělat složité dotazy, většina ORM to dovoluje a ještě ke všemu ti to vrátí v oněch entitách pokud chceš a pak to zase vysypeš do templaty . . . .
Ale je pravda, že jediné kde si to dokážu opravdu představit tak, aby mi to nikdo nevymluvil je, když vezmeš třeba nějaké Core aplikace - třeba společný admin ke kterému se pak už jenom přidávají custom weby pro klienty a u těch klientů právě sekáš ty templaty a tohle ti hodně pomůže. to jo . . ale jinak to taky rád nemám - už jsem s tím dělal v PHP, Javě, C# a něco podobného a velmi odlehčeného jsem si spíchl pro wordpress, ale já si stejně myslím, že optimalizace má smysl vždycky, protože jednou, až to bude potřeba, už může být úplně pozdě a nebo to být nereálné - např. (cena/výkon) + plánovaný rovoj . . .
Každopádně ORM nebo ne není největší problém tvorby aplikací ani náhodou . . . Už třeba jenom jmenými konvencemi, resp. jejich nedodržováním, se dá udělat harakiri v podstatě z čehokoliv - co jsem se teď naposledy setkal - Máš třeba modul "Description", někdo jeho "main" třídu pojmenuje "Labels", vytvoří z ní instanci "LevýBanner", který si dál předává funkcemi jako LB a do šablony si to pošle jako Blok1 v array "partials" a tohle ti udělá s 10 - 20 komponentama na stánce, tak se můžeš jít klouzat. A pokud tohle udělá s ORM Entitama a sloupcema ["mapping"], tak bych zrovna zařal shánět jiné místo . . . ;-)