MariaDB vs Postgres vs SQL Server

PanVP

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #45 kdy: 20. 04. 2021, 15:04:12 »

V USA si můžete na VŠ vybrat čistě teoretické obory i čistě praktické nebo mezi.
Dis. má u nás asi stejný respekt jako maturita.

Podle vaší logiky by chirurg měl být diplomovaný specialista, co se to naučí "ještě navíc k maturitě", ale politolog musí být trojitý Dr. To rozhodně odmítám.

Není důvod ponižovat praktické obory, pokud se člověk naučí vše potřebné pro svojí praxi.
Podle mého názoru jsou teoretické obory na prd a buližník.



Re:MariaDB vs Postgres vs SQL Server
« Odpověď #46 kdy: 20. 04. 2021, 15:26:15 »

V USA si můžete na VŠ vybrat čistě teoretické obory i čistě praktické nebo mezi.
Dis. má u nás asi stejný respekt jako maturita.

Podle vaší logiky by chirurg měl být diplomovaný specialista, co se to naučí "ještě navíc k maturitě", ale politolog musí být trojitý Dr. To rozhodně odmítám.

Není důvod ponižovat praktické obory, pokud se člověk naučí vše potřebné pro svojí praxi.
Podle mého názoru jsou teoretické obory na prd a buližník.

Každý ať studuje, to co mu vyhovuje, a co si myslí, že má pro něj smysl. Nejde mít všechno. Můžete míť buďto šírší záběr nebo větší hloubku. Každé má svoje pro a svoje proti. A zrovna tak každý člověk je nějaký, někomu od začátku vyhovuje specializace a jinému ne. A zrovna tak v práci - je dobré mít specialisty, a je dobré mít i lidi, kteří mají širší přehled. Důležité je, aby člověk věděl, co ví, a co neví. Ve stavařině nebo ve strojařině, když něco pokurvíte, tak to může zabít lidi, takže člověk by měl vědět, co dělá.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #47 kdy: 20. 04. 2021, 16:45:02 »

Ty problémy by měla každá databáze - ...... A)

V IT dělá každý, kdo má ruce. .... B)

A)
moje zkusenost je takova, ze kdyz se nepouzije SQL tak zadne problemy s SQL nejsou. U databazi jako ADABAS, SAP-DB, SolidDB, SAP Advanced Server, Faircom, BerkeleyDB nemusite vubec nikoho skolit na SQL , nikdo nevi co je referencni integrita a normalni formy, kdy se u jake databaze smi a nesmi pouzit jaky trigger   a presto je vsechno vpohode a ACID  :)
Aplikacni programatori si prectou na A4 papiru, jak se jmenuji ty funkce , ktere prectou data z databaze a jak se jmenuji ty, ktere neco zapisuji. Jedine co musi clovek mentalne uchopit je pojem indexu a k cemu je to dobre - ale to se dozvi kazdy programator v prvnim prikladu, kdy ma vytahnout z databaze vsechny faktury s datumem XX.XX.ZZZZ.

B)
jestli tomu rozumim, tak ten rozpor na ktery upozornuji - totiz SQL je jednoduchy koncept versus SQL nikde nefunguje poradne - vysvetlujetezrovna tak  jako nekolik ostatnich kolegu tim, ze uroven lidi v IT je spatna?
Ale co proti tomu delat? Udelat si lepsi lidi?
Nebylo by skutecne mozne, ze ta SQL technologie nastavuje prece jenom pro siroke vrstvy prilis vysokou latku?

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #48 kdy: 20. 04. 2021, 17:13:10 »
(...) SQL je jednoduchy koncept versus SQL nikde nefunguje poradne - vysvetlujetezrovna tak  jako nekolik ostatnich kolegu tim, ze uroven lidi v IT je spatna?
Ale co proti tomu delat? Udelat si lepsi lidi?
Nebylo by skutecne mozne, ze ta SQL technologie nastavuje prece jenom pro siroke vrstvy prilis vysokou latku?

Pavel to psal. Programátorům často chybí odhad, že daný úkol musí jít vyřešit lépe, případně dostatečná znalost, aby aspoň rozeznali, že použité řešení dobře nefunguje. Když vidím jednoduchý script, který má přijmout data a uložit, nebo naopak vytáhnout malá data a odeslat, a trvá 100 ms, a programátora to nealarmuje, pak to žádná technologie nezachrání. Tam chybí elementární znalosti či zkušenosti.

Stesk nad tím, jak se používá SQL není o vysoké laťce. Pokud z jakékoliv databáze, či API, či úložiště programátor vytahuje bimbobajty dat na to, aby je zpracoval na 32bitový integer, pak mu chybí základní znalost. Znalost toho, že přenášet data je časově a paměťově náročné. Mělo by to ihned indukovat myšlenku, jak získat rovnou ze zdroje ten malý výsledek. Pokud užívá jakoukoliv databázi (nemusí to být klasická SQL RDBMS), měl by vědět, že na 99 % dokáže požadovanou operaci provést efektivněji, než kód, který si napíše na náročně přenesenými daty. Tyto základy už pak nutně vedou k tomu, že vyřeší, nebo se doptá jak vyřešit úkol lépe. Ale musí to vůbec napadnout.

Typickým příkladem je paginace na stránkách. 90 % programátorů nejdřív udělá SELECT count() a poté, ihned za ním SELECT ... ORDER BY LIMIT OFFSET, přičemž oba dotazy mají úplně stejné parametry. Programátorovi musí dojít, že je nesmysl nechat databázi vyhodnotit dotaz a spočítat počet řádků a ihned poté udělat to samé a vzít si jen pár řádků do aplikace. Dvakrát stejná práce. Opět, musí to jen napadnout. To taky není o znalosti SQL.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #49 kdy: 20. 04. 2021, 17:38:30 »

Ty problémy by měla každá databáze - ...... A)

V IT dělá každý, kdo má ruce. .... B)

A)
moje zkusenost je takova, ze kdyz se nepouzije SQL tak zadne problemy s SQL nejsou. U databazi jako ADABAS, SAP-DB, SolidDB, SAP Advanced Server, Faircom, BerkeleyDB nemusite vubec nikoho skolit na SQL , nikdo nevi co je referencni integrita a normalni formy, kdy se u jake databaze smi a nesmi pouzit jaky trigger   a presto je vsechno vpohode a ACID  :)
Aplikacni programatori si prectou na A4 papiru, jak se jmenuji ty funkce , ktere prectou data z databaze a jak se jmenuji ty, ktere neco zapisuji. Jedine co musi clovek mentalne uchopit je pojem indexu a k cemu je to dobre - ale to se dozvi kazdy programator v prvnim prikladu, kdy ma vytahnout z databaze vsechny faktury s datumem XX.XX.ZZZZ.

B)
jestli tomu rozumim, tak ten rozpor na ktery upozornuji - totiz SQL je jednoduchy koncept versus SQL nikde nefunguje poradne - vysvetlujetezrovna tak  jako nekolik ostatnich kolegu tim, ze uroven lidi v IT je spatna?
Ale co proti tomu delat? Udelat si lepsi lidi?
Nebylo by skutecne mozne, ze ta SQL technologie nastavuje prece jenom pro siroke vrstvy prilis vysokou latku?

Ty databáze, které tu zmiňujete jsou buďto jednoúčelová ořezávátka, nebo hodně jednoduché kousky, které toho moc neuměly, a o to víc musel umět programátor, aby z toho na tehdejším železe něco vyrazil. A zákazník si nemohl moc vymýšlet. A také bylo mnohem méně dat. Nevěřím vám, že na tehdejších databázích nebyly problémy. Hodně projektů mělo problémy, a je pravda, že železo na kterém tyto databáze běželo, tak nebylo nic moc (z dnešního pohledu), ale uživatelé byli rádi, když dostali výsledek (v hodinách). A programátoři, kteří se k těmto databázím dostali, tak nejspíš měli hodně intenzivní znalosti tunění operačního systému, možná i psaní v assambleru.

Dneska si zákazník navýmýšlí, obchodník a projekťák bez znalosti technologie odkývá všechno, a programátor musí aplikaci do dvou měsíců předat. To, co se v době ADABASu psalo 2 roky se dneska píše 2 týdny. A zákazník očekává, že na TB dat dotazy pojedou interaktivně do vteřin (protože mu to obchodníci naslibovali). Navíc tehdejší aplikace byly jednoduché - skládaly se z pár komponent, pár vrstev - žádné železo by to jinak neutáhlo. Dneska tam máte tuny balastu. A když něco nefunguje, tak dá dost práce poznat co nefunguje. Teď měl zákazník problém s lagy, a dost možná (a možná ne) byl na vině REDIS (inmemory databáze), a nebo možná poddimenzovaný virtuál, na kterém to běželo. Klobouk dolů, co se před 30 rokama naprogramovalo, a v čem. Ale z dnešního pohledu mi to přijde jako idyla.
« Poslední změna: 20. 04. 2021, 17:44:58 od Pavel Stěhule »


Re:MariaDB vs Postgres vs SQL Server
« Odpověď #50 kdy: 20. 04. 2021, 19:24:20 »
Vinit z těch nešvarů SQL nedává smysl. Je to obecný jev napříč všemi technologiemi a ani super přímočaré a jednoduché koncepty to nezlepšují (např. JSON se používá protože je tak jednoduchý a každý ho pochopí - ale že má nějaká omezení, které přinesou problémy a odloženou pracnost, to si řada lidí neuvědomí).

Ve skutečnosti je to prostě projev změněných poměrů - jiné množství programátorů, jiný poměr počtu lidí vs. počtu počítačů, jiný rozsah kódu atd. atd.

Asi to lze řešit na osobní úrovni - kdo chce pracovat s kvalitním kódem, musí se probojovat do nejlepších kruhů, kde se děje něco zajímavého nebo běží nějaký výzkum. Jinak plave v kompromisech, které ale na druhou stranu na řadu věcí stačí a pracovat tímto stylem taky není ostuda, alespoň pokud se k nim člověk přiklání vědomě.

Jako třeba ten příklad s taháním celých dat, abych použil jedno číslo - to zase není rozhodnutí jednoho programátora, jde o množství kódu, použitý framework (často ORM, které má přinejlepším nějaký lazy loading) takže nakonec se programátor rozhoduje zda napíše nové sql dotazy (které bude muset navíc obhájit) nebo použije existující otestovaný kód pro uložení celé beany. Prostě - kompromis.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #51 kdy: 20. 04. 2021, 19:27:23 »
(...) na řadu věcí stačí a pracovat tímto stylem taky není ostuda, alespoň pokud se k nim člověk přiklání vědomě.

Jako třeba ten příklad s taháním celých dat, abych použil jedno číslo - (...) nakonec se programátor rozhoduje zda napíše nové sql dotazy (které bude muset navíc obhájit) nebo použije existující otestovaný kód pro uložení celé beany. Prostě - kompromis.

Moje zkušenost je, že obvykle to není vědomý kompromis, ale většinou neznalost, co vlastně tím způsobují.
Jinak tam, kde se jedná o vědomý a uvážený kompromis - souhlas s tím, co píšete.

PanVP

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #52 kdy: 20. 04. 2021, 23:12:54 »
Jak jsem se poprvé dozvěděl o MongoDB? Bylo to asi v roce 2016 a vedoucí projektu řekl "Na blbnutí s SQL nemáme čas!"
Zákazník očekával rozběhnutí projektu prakticky hned.

Než jsem si to osahal, myslel jsem si, že se zbláznil. Ale vývoj produktu - oproti jiným projektům - doslova uháněl. A to se zadání v průběhu projektu měnilo, jak se zákazník vyspal.

S NoSQL se člověk nesoustředí na "vyšpekulování krutopřísného Joinu", ale hloubá nad svým objektem, aby lumpík dělal, co dělat má.

Takže jeho tvrzení "Na blbnutí s SQL nemáme čas!"  zpětně považuji za pravdivé - v kontextu daného projektu.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #53 kdy: 21. 04. 2021, 10:31:21 »

Ty problémy by měla každá databáze - ...... A)

V IT dělá každý, kdo má ruce. .... B)

A)
moje zkusenost je takova, ze kdyz se nepouzije SQL tak zadne problemy s SQL nejsou. U databazi jako ADABAS, SAP-DB, SolidDB, SAP Advanced Server, Faircom, BerkeleyDB nemusite vubec nikoho skolit na SQL , nikdo nevi co je referencni integrita a normalni formy, kdy se u jake databaze smi a nesmi pouzit jaky trigger   a presto je vsechno vpohode a ACID  :)
Aplikacni programatori si prectou na A4 papiru, jak se jmenuji ty funkce , ktere prectou data z databaze a jak se jmenuji ty, ktere neco zapisuji. Jedine co musi clovek mentalne uchopit je pojem indexu a k cemu je to dobre - ale to se dozvi kazdy programator v prvnim prikladu, kdy ma vytahnout z databaze vsechny faktury s datumem XX.XX.ZZZZ.


Pokud budete používat denormalizované tabulky, a na nich si vyrobíte indexy, tak máte ADABAS. Se všemi výhodami a zejména nevýhodami. Je to jen podmnožina relačního modelu, která má dvě zásadní nevýhody: a) konzistenci si musíte ošetřit na aplikační straně, b) nad files jde dělat jenom omezený počet reportů. Pokud se do toho vlezete, tak to bude rychlé. Pokud ne, tak musíte udělat výrazně víc práce, a ještě report bude pomalý. 

Relační databáze - návrh normálních forem vychází přesně z těch zkušeností s databázemi jako byl ADABAS, a snaží se řešit problémy, které na těchto databázích byly. Byly to jednoduchý stroje, a nijak zvlášť nepodporovali kreativitu. Což je do jisté míry výhoda - nikdo si moc nevymýšlí, a nestaví vzdušné zámky. Pokud jste věděli, co to zvládne, a pokud jste zadání i realizaci s tímto vědomím, tak to mohlo fungovat. Ale to platí na 100% i o dnešním SQL. Dnešní problém je paradoxní. Výkon dnešních databází jak po stránce hw, tak po stránce sw je někde úplně jinde. Ale znalosti a schopnosti vývojářů dost degradovaly a určitě se posunuly. V dobách ADABASu se neřešil uživatelský interface - výsledkem byl papírový report. Dneska programátoři primárně řeší UI, případně integraci komponent, a skrz ty komponenty už nevidí databázi. Díky výkonu dnešních databází se to ještě většinou urve. S nějakým lehkým tuningem (indexy) většina aplikací funguje relativně dobře. Ale ten styl programování je z pohledu db ještě horší než jak se psalo vůči ADABASu. Kdyby se aplikace napsala tak, že klíčové výpočty se provedou SQL nebo uloženými procedurami, tak by mohla být ještě o řád rychlejší.

Nechci se vás dotknout - ale řekl bych, že si ty předrelační databáze idealizujete :-). V té době se fůra věcí nedělala - a) na tehdejším hw vůbec nešla dělat, b) nebyli lidi, c) nebyla data.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #54 kdy: 21. 04. 2021, 10:34:39 »
Pavel Snehule:

Co si mysliteo tom, kdyz vyvojari kvuli perfromance problemum zacnou denormalizovat tabulky v databazi? Ja si myslim, ze to je spatny postup, ze to nefunguje, a ze to akorat zvysi bordel v aplikaci. Podle me u beznych 95% servis v SOA architekture jsou perfromance issue zpusobene bordelem, spatnymi indexy a deadloky, a nema tomoc spolecneho s tim, ze tabulkuy jsou normalizovane. A denormalizace jenom prileva olej do ohne vseobecneho bordelu, ktery zpusobuje nejen problemy s perfroamnce, ale i bugy.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #55 kdy: 21. 04. 2021, 10:35:10 »
Pavel Snehule:

Co si mysliteo tom, kdyz vyvojari kvuli performance problemum zacnou denormalizovat tabulky v databazi? Ja si myslim, ze to je spatny postup, ze to nefunguje, a ze to akorat zvysi bordel v aplikaci. Podle me u beznych 95% servis v SOA architekture jsou perfromance issue zpusobene bordelem, spatnymi indexy, spatnymi sql dotazy (bordel), blokujicimi transakcemi (kvuli bordelu v kodu), a nema to moc spolecneho s tim, ze tabulkuy jsou normalizovane. A denormalizace jenom prileva olej do ohne vseobecneho bordelu, ktery zpusobuje nejen problemy s performance, ale i bugy.

Potrebuju nejakou munici na vyvojare, az budou pindat ze serivce ma performance issues a budou chtit jako prvni stupidni reseni co je napadne delat denormalizaci.
« Poslední změna: 21. 04. 2021, 10:38:00 od registrovany123 »

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #56 kdy: 21. 04. 2021, 10:59:52 »
@registrovany123

Pavel určitě odpoví, ale napíšu i já.

Denormalizace je svůdná praktika. Na jeden partikulární problém to může být efektivní řešení. Odtrhnete si data a přestanete na ně čekat, protože jsou zablokovaná.

Ta stinná stránka je přesně to, co popisujete. Denormalizace, pokud má být funkční, předpokládá, že vývojář neudělal chybu v úsudku. Může se lehce stát, že odtrhne data, která v důsledku jiných operací přestanou být konzistentní. To pak musíte pohlídat na aplikační úrovni, a to Vás opravdu může stát víc, než si dát databázi do pořádku. A jsme znovu na začátku: musí být v týmu někdo, kdo ten správný úsudek má. Pokud takového člověka v týmu máte, pak se jeho znalost dala rovnou využít k tomu, abyste se vůbec nedostal do stavu, kdy o denormalizaci uvažujete. Je to uzavřený kruh.

Osobně si myslím, že je jednodušší v týmu vypěstovat určité základní znalosti, co se dá očekávat od techniky. Programátor nemusí znát hluboce RDBMS, ale měl by rozpoznat moment, kdy se má poradit s kolegou, který je má.

Když se to nedělá (průběžně), tak se projekt může dostat do stavu, kdy už není jiná možnost, než spoustu práce zahodit a celé části přepsat znovu. To nikdo nechce. Ani zadavatel, který za to platí - tomu těžko vysvětlíte, že jste mu celý rok šli na ruku, aby měl úpravy hotové rychle, ale že po roce se velká část práce může hodit do koše a musí se refaktorovat. Je jen málo zadavatelů, kteří jsou schopni kvalifikovat důsledky rychlého vs. systematického vývoje, ale pochopitelně i takoví existují. Někdy je opravdu obchodně výhodnější "psát na prasátko" s vědomím, že se to později refaktoruje.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #57 kdy: 21. 04. 2021, 11:16:01 »
Pavel Snehule:

Co si mysliteo tom, kdyz vyvojari kvuli performance problemum zacnou denormalizovat tabulky v databazi? Ja si myslim, ze to je spatny postup, ze to nefunguje, a ze to akorat zvysi bordel v aplikaci. Podle me u beznych 95% servis v SOA architekture jsou perfromance issue zpusobene bordelem, spatnymi indexy, spatnymi sql dotazy (bordel), blokujicimi transakcemi (kvuli bordelu v kodu), a nema to moc spolecneho s tim, ze tabulkuy jsou normalizovane. A denormalizace jenom prileva olej do ohne vseobecneho bordelu, ktery zpusobuje nejen problemy s performance, ale i bugy.

Potrebuju nejakou munici na vyvojare, az budou pindat ze serivce ma performance issues a budou chtit jako prvni stupidni reseni co je napadne delat denormalizaci.

Na to se nedá jednoduše odpovědět. U OLAPu, když máte star schema nebo snowflake schéma, tak se běžně pracuje s silně denormalizovanými daty (a k tomu se používají databáze optimalizované pro OLAP - sloupcové analytické databáze - vertika, monet nebo snowflake. Tím, že máte předem známé schéma, tak pak můžete používat generické nástroje pro tvorbu MD reportů. OLAP databáze jsou ale sekundární - nejsou primární, a pracuje se tam s transformovanými daty, takže zřejmé nevýhody nenormalizované databáze jsou potlačené.

Pokud máte OLTP databázi s dobře navrženým schématem, tak si myslím, že denormalizace je blbost. Pak mraky dotazů jsou naprosto nesmyslný typu SELECT ... WHERE id = x LIMIT 1. To rozhodně výkonnostně nepomůže. Databáze má evidenci o tom, které hodnoty jsou unikátní, a dokáže tuto informaci využít. Denormalizací redukujete počet unikátních indexů. Nehledě na to, že pak, pokud musíte, tak napsat SQL v ruce bolí, a je neskutečně nečitelné, protože musíte redukovat duplicity - musíte nadužívat DISTINCT, případně zbytečně používat agregace MIN, MAX. To všechno blokuje optimalizaci a má velkou režii. Určitě denormalizací něco zrychlíte, ale dost věcí jinde si zkomplikujete a zpomalíte. Někdy na opravdu velkých tabulkách může mít smysl si přikopírovat sloupec, podle kterého budete filtrovat (někdy se vyplatí data před filtrovat před JOINem, nebo předagregovat). Ale to se bavíme o tabulkách, které mají desítky možná stovky miliónů záznamů.

Pokud se JOIN provádí na úrovni aplikace (díky ORM - kdy v cyklu v aplikaci se volá nějaká metoda, která stahuje data z db), tak se implementuje ta nejpomalejší metoda JOINu, která existuje - nested loop - navíc zpomalený velkou režií vzdálené komunikace. Stáhnout si z jakékoliv databáze 1M hodnot po jednom řádku je neskutečně pomalé. Tím, že denormalizuji, abych získal lepší výkon s ORM, tak já si myslím, že ten nejhorší způsob, co může být. Bohužel ORMka jsou natolik komplikovaná, že tahle dementní cesta, je jediná, která je dosažitelná pro běžného programátora. SQL neumí, a přetlačit ORM také ne - to není o změně ORM, ale o změně patternů (jak to ORM použít).

Pokud si nešikovně namapujete objekty do relační databáze (snažíte se o implementaci dědičnosti na úrovni databáze), tak se může stát, že ve vašem schématu nebude entitě odpovídat tabulka. Pak někdo dělá denormalizaci - ale to není denormalizace, ale materializace entity. V podstatě se dostáváte do správného stavu.

Pokud máte správně znormalizované schéma (a vaše aplikace je OLTP), tak je denormalizace blbost (defakto se snažíte vytvořit jakési materializované pohledy) pro ORM, ale pak se ta databáze hrozně blbě používá. To máte osypky, když máte napsat SQLko.

Je to podobné jako s typovým systémem. V podstatě si můžete vystačit s varcharem (a také jsem viděl takové databáze), ale ve výsledku je to dost pomalé (neefektivně uložená data, neustálé konverze), všechno si musíte udělat sami, a neupozorní vás to na chyby, na které by vás to upozornit mohlo.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #58 kdy: 21. 04. 2021, 11:21:04 »
Kdyby se aplikace napsala tak, že klíčové výpočty se provedou SQL nebo uloženými procedurami, tak by mohla být ještě o řád rychlejší.

Již tu zaznělo slovo kompromis. V reálu je databáze součástí celého řešení a troufnu si tvrdit, že aplikační část bývá podstatně složitější než úkoly prováděné databází. Budu-li honit maximální výkon s minimálními požadavky na HW, budu muset optimalizovat umístěním hodně logiky a výpočtů do stored procedures. Pokud to nemusím hrotit, budu se maximálně snažit udržet aplikační logiku v jednotném prostředí, nad kterým má plnou kontrolu IDE vývojářů (debugování, trasování, snadný refaktoring). Ano, třetí strana bude muset přistupovat přes aplikační API, ale to se obvykle stejně vytváří i z řady jiných důvodů. Pro mě je DB konzistentní storage, ideálně hodně rychlý pro složité joiny, ale aplikační logiku (tedy právě třeba ty zmiňované výpočty) chci držet ve zdrojáku aplikace, pokud mi to požadavky na výkon dovolí.

Re:MariaDB vs Postgres vs SQL Server
« Odpověď #59 kdy: 21. 04. 2021, 11:42:50 »
Kdyby se aplikace napsala tak, že klíčové výpočty se provedou SQL nebo uloženými procedurami, tak by mohla být ještě o řád rychlejší.

Již tu zaznělo slovo kompromis. V reálu je databáze součástí celého řešení a troufnu si tvrdit, že aplikační část bývá podstatně složitější než úkoly prováděné databází. Budu-li honit maximální výkon s minimálními požadavky na HW, budu muset optimalizovat umístěním hodně logiky a výpočtů do stored procedures. Pokud to nemusím hrotit, budu se maximálně snažit udržet aplikační logiku v jednotném prostředí, nad kterým má plnou kontrolu IDE vývojářů (debugování, trasování, snadný refaktoring). Ano, třetí strana bude muset přistupovat přes aplikační API, ale to se obvykle stejně vytváří i z řady jiných důvodů. Pro mě je DB konzistentní storage, ideálně hodně rychlý pro složité joiny, ale aplikační logiku (tedy právě třeba ty zmiňované výpočty) chci držet ve zdrojáku aplikace, pokud mi to požadavky na výkon dovolí.

Uznávám, že tohle je už hodně kontroverzní téma. Jednak zdrojáky uložených procedur můžete mít ve zdrojácích aplikace, jen je jiný deployment. Ono nejde ani tak o maximalizaci výkonu. Častý (typický) problém je, že vývoj probíhá nad prazdnou databází, a nad ní jsou výpočty rychlé. V momentě, kdy se tam naimportují data, tak už je pozdě něco měnit. Určitě není důvod optimalizovat na krev, na druhou stranu to zpomalení dané tím, že se databáze bere jen jako storage, a že stěhujete data mezi db a aplikací je dost brutální. To může být o řád až  dva. Což může být znatelné u interaktivních aplikací - je rozdíl jestli mám výsledek za sec nebo za deset sec, je rozdíl jestli při 1000 aktivních uživatelů mám cpu na 10% nebo na 80%. A může to být problém i neinteraktivních věcí - pokud vám denní úzávěrka běží 10 hodin a musíte ji mít spočítanou do následujích 24 hod, tak už vám moc nezůstane času na údržbu. Pokud by vám běžela hodinu, tak máte výrazně větší rezervu.

Nemám rád přístup, kdy programátoři, kvůli svému pohodlí předají aplikaci, a pak dalších deset let kolem ní tancují admini,  a uživatelé se můžou učekat. A programátoři jsou v pohodě - mají zdrojáky na jednom místě.