Vlákno názorů k článku Migrace aplikace z Oracle do PostgreSQL od lobo - clanok je dobry, business logic v databaze je...

To minus mas ode me, ukliknul jsem se, promin.

Pane Stěhule, melete to samé pořád dokola! Obchodní (business) systémy pracují s entitami, které mají z povahy věci vlastní vnitřní seznamy a vzájemně jsou uspořádány do grafu. Dokumentová DB zvládá ty seznamy, grafová či objektová oboje. RDB ani jednu z těchto dvou vlastností neumí!!! Takže to musíte v oné RDB nějak nasimulovat, a to rozkladem do tabulek a poté jejich opětovným spojováním. Jestli tvrdíte, že v uložených procedurách se obejdete bez ORM, tak se mýlíte, protože právě to dohledávání jednotlivých částí obchodních entit v tabulkách je právě ono ORM, i když v takové primitivní podobě.
Takže shrnuto: Obchodní systémy jsou grafové, k čemuž opravdu nemusíte užít objekty, ale je to velice výhodné. Naopak jejich uložení do RDB je snad nejhorším možným způsobem uložení a zpracování (myslete si o tom, co chcete). Samotné uložené procedury pak znamenají se svým procedurálním členěním, omezenými datovými strukturami a nízkou abstrakcí uvíznutí v informačním středověku.
Mimoto zaměňujete příčinu a následek - ORM není jedním z nejhorších nápadů v dějinách IT, to je jen řešení původního průseru, a to použití RDB na grafové systémy.

O použití Postgressu jako dokumentové DB tu nikde řeč nebyla. A máte na mysli předstírání organizace dat do dokumentů, nebo uložení jako dokumenty?
Nemluvil jsem o uložení v grafech, ale o tom, že obchodní systémy JSOU grafy!
Rel. model nepřináší žádné zjednodušení, je to jiná organizace dat! A na to zvládání úloh mám mnoha lety podložený vlastní názor.
Ufff... Nejde o to, čím se začínalo, ale co je teď!

Asi to tu nemusíme protřepávat, zjevně si nerozumíme, vy se budete věnovat svým RDB, já zase něčemu jinému. Svoje názory jsme řekli.

Takže to musíte v oné RDB nějak nasimulovat

To je nepochopeni RDB. Rozklad do tabulek a jejich skladani nic nesimuluje. To je jen jiny zpusob reprezentace informaci (dat).

Jestli tvrdíte, že v uložených procedurách se obejdete bez ORM, tak se mýlíte, protože právě to dohledávání jednotlivých částí obchodních entit v tabulkách je právě ono ORM, i když v takové primitivní podobě.

Neni. ORM (Object-Relational Mapping) je jen zpusob, jak namapovat objekty na relacni data a opacne. Coz je opravdu jeden z nejhorsich napadu. Hlavni problem je v tom, ze v objektovem sveta je objekt (entita) dan svou identitou, mistem prirazenym v pameti. V RDB svete je objekt (entita) dan svymi vlastnostmi (prinejmensim hodnotami prim. klice). Toto na sebe naroubovat a nezblbnout, chce dost prace.

Pri pouzite ORM typicky vznikaji dva problemy. Nepochopeni objektoveho programovani nebo nepochopeni relacnich db. A pak z toho vznika prasepes s hromadou problemu.

Obchodní systémy jsou grafové

Nikoliv nezbytne. Zalezi jenom na tom, jak se na ta data chcete divat. Jestli jako na nejake objekty, ktere jsou spolu provazany (to chces ty), ci na hromadu informaci, ktere se daji ruzne transformovat pomoci par jednoduchych operaci. (to chce p. Stehule)

On ale zmínil právě PLSQL. To je programovací jazyk implementovaný v Oracle.
A také psal o "business logic", což je procesní model. S objekty to nemá nic společného. To jsou takové ty diagramy "přijde požadavek na vložení objednávky, ověřím, že zákazník existuje, ověřím, že zákazník nemá credit hold. Pokud má credit hold, tak ověřím, zda požadavek má nastavený příznak ignorování credit holdu..." To snad dnes do objektů necpe nikdo? V čem by tam komu objekty pomohly?

Pokud použijete ORM, tak necpěte žádnou logiku do databáze. Prostě si při startu aplikačního serveru stáhněte všechna data a udělejte si z nich vlastní model v paměti. ORM vrstva pak bude sloužit jen k tomu, že změny zapíšete do databáze tak, aby si je aplikační server mohl znovu stáhnout po restartu. Pokud nemáte dost paměti, tak si můžete ORM vrstvu upravit tak, aby tahala data jen k těm objektům co právě potřebuje. Plus nějaký garbage collector co je zase uvolní až nebudou potřeba.

Kombinovat ORM a PLSQL je prostě kravina. Pokud to děláte, tak se střílíte sami do nohy. Pak se nedivte, že to kulhá.

Klasický problém rozhodování mezi variabilitou řešení a nějakým výkonovým bonusem, o kterém se dlouze můžeme bavit, jestli stojí za to. Jak to funguje v praxi?
Třeba takový SAP zákazníkům oznámil, že od verze S/4 prostě budou mít natvrdo HANA a kdo dosud spokojeně provozoval třeba Oracle, může si jít trhnout nohou. Jakmile těch databází máte víc, začne mít význam otázka, zda je vůbec chytré mít pro každou aplikaci databázi od jiného dodavatele, protože ten bordel je pak radost spravovat.

Takže když nemáte business logic v databázi, můžete se jednou prostě rozhodnout, že místo v Oracle budete provozovat MS SQL nebo třeba ten Postgress, klient v ideálním případě jen změní ODBC driver a jede se dál. Divil byste se kolik drahých a profesionálních řešení takto funguje, protože zákazník si chce databázi volit sám.

Tak si tu otázku otočte. kolik takových brutálně výpočteních aplikací je? Naprosté minimum. Většina databází jen zapisuje transakce a odpovídá na různě komplikované SELECTy. Rozdílu ve výkonu si nikdo nevšimne. Zato nutnosti koupit licenci na ORACLE, když má firma volné licence k MSSQL, to už za povšimnustí stojí. Stejně jako povinnost najednou provozovat jinou databázi než zbytek firmy. V mém předchozím zaměstnání jsme měli desítky aplikací, hromadu Oracle databází, lidi co tu tento typ DB dobře znají, a všechno provozováno na clusteru s RedHatem. No a když pak najednou nějaký inteligent vyrobil nebo nakoupil nějaký super SW, který měl logiku zadrátovanou v MSSQL a nešel na ničem jiném provozovat (ono stačí když má aplikace driver jen pro jednu DB), najednou jsme museli řešit, kdo to bude supportovat, kde se to bude provozovat (na RedHat/Oracle Dlusetru asi těžko), k tomu nějaké to školení (protože to bylo první MSSQL ve firmě) a takhle bychom mohli pokračovat. Situace totálně k hovnu. Proto business logic do DB, není li to nezbytně nutné, fakt ne.

BTW neumím posoudit zda má MySQL stejné možnosti pro mission critical naazení jako ORACLE, nicméně o tom fakt pochybuji.

Mission critical je cokoli, kde hodinový výpadek způsobí "velké ztráty". Skutečně nechápu, proč by u systému, kde výpadek 1hod je zcela nepřijatelný a maintenance se plánuje jednou ročně na svátky, neměla být relační databáze. V drtivé většině těchto případů je totiž použita právě relační databáze.

Toto nijak nerozporuji. Hlavní rozdíl mezi Oracle vs. MySQL + Postgres bude celý ten cirkus okolo placeného supportu, certifikací, garancí apod., které ovšem tvoří důležitou součást rozhodování v korporátech. Sehnat někoho, kdo vám smluvně něco garantuje bude asi výrazně snazší s Oraclem.

To že velké Internetové firmy používají OSS databáze svědčí o tom, že to jsou možná lepší řešení než proprietární Oracle. Když na to máte prostředky a lidi, můžete si to tunit dle libosti, a nejste závislý na tom co vám chlapci z Oraclu milostivě sdělí a dovolí. Ta firma má horší pověst než Microsoft :-D

názory hezké, poté příjde požadavek na auditing, goverance, nějaké to ISO a jiné korporátní úžasnosti a vaše MySQL,Postgres s REST API či mnoha napojenými aplikace neuspěje.

Postrgres pořád trpí v HA, integrace s LDAP není bezproblémová, dělat snapshoty není ono, tady třeba Oracle, Teradata, db2 (či jak to pojmenovali letos) vítězí a není to srovnatelné s open source.

Tím nebojuji za druhou stranu, mám tyhle open source databáze rád, nepotřebuji certifikace, velké manuály a vše si nastuduji ze zdrojových kódů, problémy se dají řešit přímo s vývojáři a ne indickou podporou. Jen někdy objektivní rozhodování právě odůvodněně končí u těhle velkých a drahých zmetků.

Důvod proč internetové firmy používají OSS je nepřítomnost státní regulace, GDPR ukáže jak si na tom OSS stojí. U těch opravdu velkých společností došlo k vytvoření vlastních technologií, které už nejsou otevřené a drží si je pod pokličkou, do komunity uvolňují jen drobky, mluvím o Googlu, Facebooku a dalších.

Osobne nemam vylozene spatne zkusenosti s oracle supportem, nehlede na to, ze ho zas tak casto nepotrebuju. Vse je o lidech. Pokud ma firma Oracle DB (z jakehokoli duvodu), tak k nemu musi mit i opravdu zkuseneho DBA, ktery dokaze nejen rozsirovat datafile. To stejne plati i o oracle pl/sql vyvojarich. Ono kdyby si kazdy precetl developers guide, tak tam se docte hodne uzitecnych informaci co a jak a kde pouzit, aby ta aplikace slapala dobre. Za me je Oracle naprosto vynikajici databaze, ktera nabizi neskutecne mnoho moznosti co se administrace i vyvoje tyce. (samozrejme ze administruji prevazne Oracle, takze proto ta chvala ;-)

Ne, tyhle velké firmy nepoužívají Oracle zejména kvůli ceně licencí. Pokud jste velká fabrika, tak si na ten Oracle za milion dolarů vyděláte. Pokud jste Facebook, tak už je pro vás výhodnější si najmout armádu lidí, než platit Oracle za licence stovky milionů dolarů.

Zkrátka proti sobě bojují dvě křivky: mzdové náklady na vlastní lidi a fakt, že Oracle má licence za procesor. Od jistého počtu procesorů se vám tudíž vyplatí mít vlastní lidi, co budou udržovat něco levnějšího. Do jistého počtu je naopak levnější držet si jediného pičičmundu DBA a zaplatit si jednou za šest let licenci Oracle.

Obecne by se s tim nazorem dalo i souhlasit. Jsme se tedy trosku v diskuzi odchylili od tematu clanku, ale ja mam pocit, jako by hodne lidi v DB videlo pouze ty ulozene tabulky a nic vic. Oracle je drahy, ale taky za tu cenu nabizi opravdu hodne a je jen na firme, aby dokazala vsechny feature vyuzit, coz se (podle me) v 95% nedeje, ale to neni problem Oracle. Uz jenom to, ze kazda feature ma tisicistrankovou doc o necem svedci a to si dovolim tvrdit, ze Oracle ma zdaleka, zdaleka nejlepsi dokumentaci (pisu o DB dokumentaci).

Jestli má vlastnost tisícistránkový popis, tak je to především důkazem, že soudruzi z Oracle to trochu překombinovali (připomínám KISS).

Bylo to mysleno tak, ze je veliky rozdil v dokumentacich pro dany produkt. Co jsem se studoval dokumentaci k mssql,db2, mysql, tak vsude se tak nejak skace od niceho k nicemu. V oracle dokumentaci je vse krasne a jednoduse popsano a vysvetleno, ma to hlavu a patu a snadno se v tom orientuje.

Jeste je tu jeden faktor. Oracle je totalne zabugovane databaze. Opravdu jsou v stovky chyb ktere nikdo neresi. Pokud ale postupujete podle booku (guidelines) tak na tyto chyby prakticky nikdy nenarazite. A na kazdy problem, ma Oracle reseni. Chete HA, mate sadu reseni na HA. Chcete replikaci, sifrovani, messaging, ... na vsechno existuje guideline, technologie, priklady. Jakmile ale zkusite neco "originalniho", tak tezce pohorite.

Postgre, na to jde uplne obracene: "Mas roota? Tak si pomuz sam".

Samozrejme se ten prvni pristup vyce vyhovuje velkym korporacim, ktere mohou ze dne na den prenest podporu nekam do Asie, a porad maji jistotu ze je v nejhorsim pripade z problemu dostane Oracle support. Zatimco druhy pristup vyhovuje start-upum jako je Google anebo Facebook, ktere jsou zvykle spolehat na vlastni zamestnance.

Tohle jsem zažil v jedné známé, čistě české, větší firmě (a nepochybuju o tom, že to tam tak chodí doteď): Systém se nasazoval u zákazníků, přičemž každý měl jiný typ databáze - všechny draze licencované, všechny stály za hovno (2 z nich tu už padly). Takže o databázi bylo rozhodnuto zákazníkem, systém tedy musel umět pracovat se všemi. Vzhledem k tomu, že aplikační logika byla z velké části nadrátovaná do DB, všechno se dělalo 3krát, protože, jak víme, databáze nejsou kompatibilní nejen v PL/SQL, ale často ani jen v SQL. Každá z nich se ladila jinak (a to těžce). Umrdalo se na tom UKRUTNÉHO času, a když říkám UKRUTNÉHO, tak tím myslím UKRUTNÉHO. Triviální operace řešitelné ve vyšším jazyku se složitě patlaly v procedurální DB. V podstatě se většinu času jen řešilo, jak co v PL/SQL spočítat a jak to potom opravit, když to bylo blbě. O vyjadřovacích schopnostech PL/SQL se tu předpokládám nemusím rozšiřovat. Vzhledem k tomu, že systém byl podstatou objektový, je jasné, jak „jednoduché“ bylo dělat změny v objektech rozstrkaných do tabulí. Nějakou konzistenci dat při čtení objektů z více tabulek více připojenými klienty tu ani nezmiňuju. Do toho každý klient přistupoval do DB extra a řešil si konzistenci (tím nemyslím pár posraných cizích klíčů) sám.
Správným řešením je nechat DB jako ukládadlo, nad to aplikační server, který si jako jediný a sám pořeší persistenci (třeba nad několika databázemi i různých typů, či službami (HTTP), prostě zdroji, nak kterými řeší konzistenci), a přes API aplikačního serveru nechat komunikovat dohodnutým protokolem klientské aplikace (v jakékoliv technologii; u objektových systémů pochopitelně objektově). TEPRVE AŽ při potřebě optimalizace vyhledávacích či výpočetních operací jich pár zadrátovat do DB. Drtivá většina operací typu „otevři formulář s fakturou“ nebo „překontroluj fakturu“ žádnou optimalizaci nepotřebuje, naopak řešit takovouto vysokoúrovňovou úlohu v DB je PEKLO!!!
Když slyším, jak se někdo snaží 300 000 řádků sraček překydat do jiného chlívku, je mi na blití. Ale kdo chce kam, pomozme mu tam.

"systém byl podstatou objektový" ... no jo, a co jineho jste pak cekal od relacni databaze? od kdy je PL/SQL objektovy jazyk, potazmo SQL? zamyslel jste se nad tim vubec?

Pane nick1, my se nyní nebavíme o skutečnosti, že objektový systém v relační DB je složitý, nyní řešíme, kde má ležet aplikační logika, zda v DB, nebo vyšší vrstvě (bez ohledu na typ DB). To, že v dané firmě o jiných typech DB nemají ponětí a že je práce s RDB do aplikací tak zadrátovaná, že je stejně nenahraditelná, je věcí jinou. Mimoto připomínám, že RDB pro objektové systémy je dodnes považována za standard(!!!), ale já nejsem člověkem, kterému byste to měl vysvětlovat!

Myslim, ze tady doslo k nedorozumeni, ja jsem prave myslel nejake napr. PLSQL API :) Tzn. co jen jde a dava to smysl, zpracovavat primo v DB a nahoru do aplikacni vrstvy vracet idealne jen vysledky a pokud to jen jde, neumoznovat primy pristup k tabulkam a pohledum.
Samzorejme situaci, kdy zeshora budou volat v cyklu sluzbu misto jeji davkove verzy, tohle nevyresi, to je zas problem na jine urovni. Ale nekde zacit je potreba :)
A jeste jeden muj postreh, nemuzu se obranit pocitu, ze spousta vyvojaru zcela nepochopila (a tedy nedocenila) rozdil/vyhodu RDBMS a tak je pouzivaji spis jako KV-store.

dannak "spousta vyvojaru zcela nepochopila (a tedy nedocenila) rozdil/vyhodu RDBMS a tak je pouzivaji spis jako KV-store"
Mne bolo Nemcami vysvetlene ze pouzivaju tabulky bez vezieb preto ze ked bolo treba nieco v poprepajanej databaze zmenit tvrdo narazili tak napisali pravidlo ziadne vezby BODKA. Vezby su presunute do logiky programu. No co s nimi :-)

...a pak se do tech dat sahne jinym kanalem a je po pravidlech/con­straintech :/ jedna apka neco zapise a druha na tom pak vesele zhavaruje :)

V okamžiku, kdy konzistenci řešíte mimo DB, tak je snad pochopitelné, že do té DB nebudete jebat kdekým ze všech stran, ale jen přes vrstvu, která to řeší.

„Samzorejme situaci, kdy zeshora budou volat v cyklu sluzbu misto jeji davkove verzy, tohle nevyresi“
Nikde není napsáno, že nemůžete mít vedle operace pro jednotku i dávkovou operaci.

„když to databáze umějí“ - Bavíme se tu o obchodních systémech, což jsou snad všechny objektové, ne relační.
„správně napsaná aplikace nad SP bude vždy rychlejší“ - To nemusí být ale vůbec pravdou.
„a (můj osobní názor) čitelnější“ - To už vůbec ne.
„SP vás donutí do dekompozice“ - To jako do procedur? S možností vzájemné komunikace přes primitivní hodnoty, nebo až tabulky? Chcete tím stavět dekompozici do objektů na stejnou úroveň abstrakce?
„Navíc SP vám umožní zabezpečení, které v aplikaci nikdy nemůžete dosáhnout.“ - :O To je jaké zabezpečení???
„U Oracle PL/SQL se používá jeden z nejlepších a velice dobře navržených programovacích jazyků - je to založené na ADĚ“ - Dosahuje to alespoň abstrakce Javy? A které další RDB to ještě mají?

"SB" je webový vývojář, používá ORM a nemá moc přehled z jiného světa. Tím ho nekritizuji, jen by bylo vhodné to zmínit, pokud se pletu, rád mě opraví.

Veškerý tyhle objektové a ORM srandy končí třeba v momentě, kdy potřebuji obyčejný data masking, nechat to na doménové vrstvě není dobrý nápad a nepatří tam, řada úniků to jen dokazuje.

Představa, že v aplikaci modeluji byznys procesy mě skoro děsí, stejně tak, když potřebuji řádně rozložit náročné výpočty napříč clusterem, opět se to na aplikační úrovni moc řešit nedá. K tomu jsou určené procedury.

V řadě případů to je ale kanón na vrabce a nehodí se k nasazení, jinde to je skoro nutnost a potřebuji tyhle enterprise warehousy. Článek příjemně popisuje jeden proces změny, vynikající, to ale neznamená, že správná volba je jen jedna databáze/techno­logie, naopak její správný výběr je důležitý, ne každá se na vše hodí.

Toho webového vývojáře si vyprošuju!

Tak tomu říkejte grafový systém, jak činím v nových příspěvcích, abych vás neiritoval. U (jednoduché) docházky se to snese, ale co u složitých systémů? Jak se u nich má graf k uložení do RDB? Jak se změní odpovědi na moje otázky?

To je možné, důsledkem ovšem je, že tím slučujete persistentní a aplikační vrstvu, takže, jak už se tu probíralo, umísťujete aplikační logiku do DB, místo abyste to (včetně bezpečnosti) nechal řešit ap. server.