Problem neni v tom co to umi nebo neumi, problem je, ze oracle je drahy (a neni rec jen o porizovaci cene). A to drahy = i pro velke korporace.
Defakto to ve finale vypada podobne, jako kdyz managementu poridite Ferrari = velmi vysoka porizovaci cena, velmi vysoke provozni naklady, a po silnici se s tim vlastne moc jezdit neda (=vyzaduje to specifickou infrastrukturu).
Tak muzu hovorit pouze za Oracle db a to z admin pohledu. Muj nazor je takovy, ze co se tyka administrace, instalace, provozu, ladeni, dokumentace, a vseho dalsiho mozneho, tak oracle nema konkurenci a dlouho ji asi ani mit nebude. (mam i mensi zkusenosti s admin mssql a db2). Samozrejme ze mensi firmy, startupy apod. asi sahnou po nejakem open source reseni, ci necem levnejsim nez je oracle (a jak zde jiz je napsano, kazda db se hodi na neco jineho), ale pokud se jedna o hard core business co vladne svetu, tak tam asi bude jeste dlouhou dobu prevazovat oracle ... ale treba se pletu a budu se muset v budoucnu preorientovat na admina jineho db systemu ;-) .. ale nerad ...
Nějak mi to nedává smysl - můžete to prosím trochu rozvést?
>> Tam není co opravovat - dokud aplikace neukončí transakci, tak Postgres sám o sobě ji nemá co ukončovat.
Nepsal jsem nic o ukončování transakce ze strany databáze, s tématem to ani nijak nesouvisí - nechápu, co řešíte.
>> Tady se jedná o zřejmou aplikační chybu.
Od kdy jsou try-catch konstrukce "zřejmou aplikační chybou"? Problém PostgreSQL je, že try-catch logiku neumožňuje - jakmile např. spadne insert kvůli duplicitním hodnotám, už není možné v transakci nijak pokračovat (každý další dotaz ve stejné TX spadne s chybou "current transaction is aborted, commands ignored until end of transaction block"). Přitom z aplikace není problém spadlý insert legitimně ošetřit a v transakci pokračovat - v mnoha use casech jde o nejjednodušší a nejefektivnější řešení, a všechny normální databáze to umožňují...
>> Postgres se rozhodně nesnaží emulovat chyby v designu Oracle.
Tak ten je dobrej :)
Pokud spadne libovolný příkaz v transakci, pak je nutné transakci rollbackovat .. tím máte vždy garantovanou konzistenci databáze. Postgres Vám nedovolí ignorovat chyby - ne jednoduše. Pokud očekáváte problémy s některými příkazy uvnitř transakce, tak byste měl použít SAVEPOINTs.
Ano, já vím - to jsem právě původně psal: v PostgreSQL se totéž dělá jinak (složitěji), proto je pracné a drahé portovat z ostatních databází na PostgreSQL. A proto těžko bude PostgreSQL významnou konkurencí pro Oracle - Oracle se nasazuje pro velké projekty, a u těch bude portace příliš drahá...
Záleží na tom jak je aplikace napsaná - podle statistik NTT cca 50 procent jde do několika dnů, 25% do 10 pracovních dnů, a zbytek mohou trvat měsíce - Oracle má hodně specifik, ať už nestandardní ztotožnění NULLu s prázným řetězcem, generické typy date, number a v jejich případě hodně tolerantní typový systém. Tam je pak migrace pracná - většinou je to srovnatelné se značným refaktoringem. Případně mohou aplikace využívat některé specifické vlastnosti Oracle - ať to některé balíčky nebo sekuritní nebo korporátní fíčury. Takových aplikací zase ve výsledku moc není - i když někteří vývojáři byly kreativní.
Hezká statistika. Naše aplikace nepoužívají žádné vendor-specific feature, protože podporují vícero databází a jakékoli neuniverzální SQL je proto nepohodlné a problematické (výhybky máme jenom tam, kde je to nutné z důvodu funkčnosti -např. rozdílná syntaxe pro TOP- nebo kde bylo možné performance problémy vyřešit pouze pomocí hintů). Ale jsou to velké projekty, a proto najít, přepsat a přetestovat všechny části, které mají try-catch implementaci, je prostě pracné = drahé. Nemapatuju si přesně odhady, ale bylo to tolik, že to management bez rozmýšlení zamítl.
tak drahy ... kdyz mate miliardovy business, tak ty licence utahnete. nehlede na to, ze jsou urcite mnozstevni slevy, akce apod ... co se tyka infrastruktury, tak vsechno neco stoji, ale produkcni db, at je to oracle nebo cokoli jineho si na normalni PC taky nedate ... proste z meho pohledu oracle jede a jeste nejakou dobu pojede ... nemam strach ...
Mimochodem, zrovna PostgreSQL se u nás neuchytil, protože je složité na něj přejít - chová se zásadně jinak než ostatní databáze v případě, že uprostřed transakce nějaký dotaz skončí s chybou, viz např. zde:
https://stackoverflow.com/questions/10399727/psqlexception-current-transaction-is-aborted-commands-ignored-until-end-of-tra
Když už máte odladěnou a léty prověřenou složitou aplikaci, tak přeportovat ji na PostgreSQL je extrémně drahé. A právě takové aplikace typicky běhají nad Oraclem (pro jednoduchá/menší řešení je Oracle zbytečně drahý). Takže zrovna PostgreSQL pro Oracle moc konkurencí není (pokud tedy mezitím chování transakcí neopravili - je to asi rok a půl, co jsem to zkoušel prošťouchnout).
Ani jedno. Oracle je řešení pro velké databáze, PostgreSQL je levné řešení pro menší objemy dat, Mongo je šikovné úložiště pro některé use case - ale jen pokud vyvíjíte v Javě. V naší firmě se používá asi 6 různých databází - právě proto, že každá nabízí za jiné peníze jinou muziku...