Nechci být otravný, ale připadá mi to jako prostý PR na komerční produkt příp. školení. Z webu firmy se člověk toho moc nedoví, působí jako spíchnut za 2h pro tento účel. Žádné info z praxe o nasazení, referencích... Prezentaci SW pro firemní řešení si tedy představuji jinak, ne web nad Wordpressem.
Mohl, predstavte si ze mate DB ( dejme tomu Oracle ) ... vezmeme si treba telekomunikacniho operatora. No a vystavujete faktury ... takze pro jednoduchost budeme uvazovat uplne nejhloupejsi model 2 tabulky, v jedny hlavicku faktury, v druhy radky faktury ... ten operator ma za sebou nejakou historii, takze uzivatel "clickne" vystvai faktury a zmeni miliony zaznamu v databazi ;-) no a pak bude chtit zmenit policka zpet ? Trochu blbost ne ;-).
Navice tyhle super cuper frameworky funguji maximalne tak na skolnich prikladech .. "vypujcka knih" apod. :-).
Za svoji karieru, jsem videl takovejch zprasenejch navrhu db modelu ze v sypce neni tolik zrni ... tak uz jsem na tyhle synteticky clanecky asi mirne vysazenej, ja chapu ze autor to mysli dobre, ono obecne napsat "smysluplnej" clanek o RDBMS/OLAPu/NOSQL nebo necem podobnym neni jednoduchy a bohuzel je k tomu potreba najit clovek ktery ma 2 zakladni vlastnosti ... VI o cem pise a UMI to napsat ctivou formou a tech proste moc neni ;-)
Jo napr. oracle ma DBMS_FLASHBACK coz je neco co "univerzalne" resi "navrat zpet v case" a jeste jsem nevidel moc lidi co by to pouzivalo, tim nerikam ze neexistuji. Podobne je to s DBMS_AQ, lidi to pouzivaji ale o tom ze to existujue vi taky jenom nekteri ..
Kdyz jsme napriklad hledal nahradu za Oracle AQ v open source svete, tak jsem nasel PGQ pro Postgresql, asi to nejak funguje, ale kdyz clovek srovna to jak to resili chlapci od Oracle a chlapci od Postgre, tak ti chlapci od Oracle vedou 1:0.
OK. K 1. odstavci, tady se Vám to asi popletlo, protože poslední větě nerozumím:
"...ten operator ma za sebou nejakou historii, takze uzivatel "clickne" vystvai faktury a zmeni miliony zaznamu v databazi ;-) no a pak bude chtit zmenit policka zpet ? Trochu blbost ne ;-)."
Můžete to trochu rozvést, abych správně reagoval?
Pokusim se odpovedet za BrainLess:
Pokud se mam v db vratit zpet, je jediny konzistentni zpusob a to rollback. Ovsem kdyz neco blbe zmenim a zaroven probiha vyuctovani pro stovky tisic zakazniku, tak to znamena vratit komplet vsechno - a to nejen z te poorane databaze, ale i ze systemu, ze kterych se pocitaly faktury. Strucne: megapru...svih.
Myslím, že pod „vrátit zpět“ bylo myšleno odvolat změnu provedenou uživatelem – když si uživatel uvědomí, že udělal chybu. Určitě to neznamená rollback transakce (ta je dávno commitnutá), a určitě to neznamená obnovu databáze ke stavu před provedením transakce (protože všechny ostatní změny byly v pořádku). Řeší se to běžně, často se to dělá pomocí storna, tj. existuje záznam o změně a pak záznam o odvolání změny – tenhle způsob odvolávání změn byl vynalezen dávno před počítačovými databázemi.
Ovšem tohle neřeší aplikační framework, musí pro to být navržena struktura databáze. Aplikační framework může nanejvýš poskytnout podporu pro snazší práci s historií – ale musí umět pracovat s tou strukturou, kterou používáte ve své databázi.
>Kdyz jsme napriklad hledal nahradu za Oracle AQ v open source svete, tak jsem nasel PGQ pro Postgresql, asi to nejak funguje, ale kdyz clovek srovna to jak to resili chlapci od Oracle a chlapci od Postgre, tak ti chlapci od Oracle vedou 1:0.
no pokud člověk potřebuje message queuing tak by IMO měl použít specializovaný SW (RabbitMQ, ActiveMQ, Kafka, a desítky dalších) a ne "přiohnuté řešení" v podobě PGQ (Oracle AQ vůbec neznám, takže zde nehodnotím, jeslti je to přiohnuté řešení ač mi tak na první dobrou připadá)
Jinak souhlas
OracleAQ je option ( nezpoplatnena naprozdil napriklad od partitioningu ) Oralce. Je to integralni soucast jadra DB + navazany API a proste to funguje ( umi to vsechny takovy ty bezni veci co by clovek od messagingu ocekaval, mlutiproducer/multiconsumer/priority/correlation/message grouping atd. )
Priznam se RabbitMQ neznam, s ActiveMQ jsem koketoval ale jejich C/C++ API je i po dost dlouhe dobre vyvoje v plenkach ( a ma to buggy, tusim ze jsme pred lety s kolegou nejakej patch do ActiveMQ poslali ). Co citim jako problem je ze vetsina tech messagingu je dneska "java oriented".