Názor k článku Sčítání.cz: jak to příště zvládnout lépe aneb úvahy o dnešním IT od Ján Regeš - Souhlasím. Když už jste zmínil databázi a článek...

Souhlasím. Když už jste zmínil databázi a článek pojednával hlavně o výkonu - já osobně databázi vnímám jako srdce každého projektu a její kvalitní návrh vnímám jako základní stavební pilíř pro dlouhodobou udržitelnost projektu. Hodně programátorů v tomto se mnou nesouhlasí a srdce vidí spíše v aplikačním kódu. Ruku na srdce - jakýkoliv kód starší pár měsíců, bude každá další generace programátorů, či programátorů preferující jiná paradigmata, kritizovat a chtít přepisovat. I ten samý tým po pár měsících, nedej Bože, po letech.

Z praxe vím, že naprostá většina výkonnostních problémů, které nešli vyřešit v řádu desítek minut, souvisela s nevhodným návrhem, či prací s databází. Ať už šlo o jakoukoliv formu databáze.

Dobře navržená databáze pouze s minimem úprav, v mé praxi často přežila i několik úspěšné zvládnutých FE, či dokonce BE přepisů v průběhu let. Pro lepší kontext - vedle role hlavního vývojáře, jsem byl pro cca. 20 projektů i analytikem a architektem, kde jsem navrhnul kolem 1 000 DB tabulek pro OLTP i OLAP workload. Omlouvám se - vím že to zní jako chlubení, ale je to pravda :-) Řešil jsem desítky výkonnostních potíží v mých či cizích projektech. Za všechny projekty dodnes po výkonnostní a celkově provozní stránce, zodpovídám v režimu 24x7 a jakékoliv faily si beru osobně.

Při realizaci projektu jsem vždy začínal a učil i mé kolegy postup, kdy je na začátku potřeba precizně domyšlený, okomentovaný, konzistentní návrh celé relační databáze. Ideálním podkladem byla kombinace funkční specifikace a wireframů všech aplikačních obrazovek. Takový luxus jsme ale někdy neměli - to známe všichni. Návrh databáze zahrnoval rovnou i případné views (typicky pro složitější agregace, se kterými by aplikační vývojáři zbytečné bojovali), triggery, constrainty a občas i funkce či procedury, které by byly v aplikačním kódu extrémně neefektivní. Zde ale musím přiznat, že jsem u jednoho z projektů udělal fail a značný část business logiky je i v databázi, co se zpětné ukázalo jako nešťastné, pokud v projektu není dobrá zastupitelnost pro složitější SQL. Obecně pro časovou představu – pro projekt o rozsahu 1 000 hodin vývoje, tento detailní návrh databáze zabral cca. 50-100 hodin. Obvykle ale při implementaci nebyly potřeba žádné změny, nebo opravdu pouze minimálně.

Z navržené databáze se pak automaticky generuje/přege­nerovává celá aplikační ORM vrstva, která pozná a generuje natypované atributy pro belongs-to, has-many i many-to-many relace. V kódu a anotacích odpovídajícím jednotlivým tabulkám a sloupečkům, pak aplikační vývojáři vidí, jak/kdy/proč/co do těchto tabulek ukládat. I když projekt vyvíjí hodně vývojářů, ukládání a workflow práce s daty je jednotné, efektivní a přímočaré. Vývojáři používají striktně natypovaný kód, všude jim všechno hintuje a když se náhodou DB struktura změní a ORM přegeneruje, statická typová kontrola hned poukáže na nekompatibilní kód. Vývojáři taky vědí, kdy můžou použít cache i jak ji invalidovat, kdy mají použít transakce, jak dát ORM vrstvě optimalizační hinty u některých složitějších dotazů, či kdy naopak ORM vrstvu pro fetch dat nepoužít a pouze si od ní získat plánovaný SQL dotaz.

Dopředu jsem vnímal a znal potenciálně výkonnostně riziková místa a měl úvahu nad tím, jak bych je případně efektivně vyřešil v řádu minut či max. jednotek hodin. Některé byly třeba o nahrazení per-query agregovaného sloupečku ve view za indexovaný virtuální sloupeček, nebo fyzický udržovaný triggerem. Některé byly o tom, že je bude agregovat periodicky DB eventa na pozadí. Některé o tom, že aplikačním vývojářům řeknu, aby některé sloupečky plnili pouze zástupkou a v předpřipraveném sloupečku přednastavili status “in-queue“ a budou se dopočítávat paralelně na pozadí úplně jinými procesy. Často se tím povedlo zabránit zbytečnému overengineeringu a preventivnímu zavádění dalších technologií, které sebou nesly další problémy k řešení.

Vím, že je to opačný přístup k některým paradigmatům, kdy je struktura databáze pouze vygenerovaným derivátem aplikačního kódu (typicky u DDD, BDD či FDD s klasickým uchopením ORM). Může to být ale dobrý námět pro další článek. Následná diskuze by mohla být velmi inspirativní a poukázat na další silné či slabé stránky možných řešení. Všichni máme různé zkušenosti, různé projekty, různé týmy, různé technologie...