Tak vymlouvat se na podporu výrobce databáze při opravě transakčního logu je jen okraj ledovce, po kterém to řešení klouže celé dolů. Zvlášť , kdy jde o MS, který funguje transparentně a jejich technologie pro eCommerce zrovna určeny nejsou. Po prohrané bitvě se generál nenajde..... většinou. Spíš se naleznou vykladači, kteří hledají příčiny a následky a v zásadě se většinou neshodnou. Technická příčina na úrovni poli je jistě jen obětní beránek, protože jinak je vše úplně v pořádku. A toto se nám stává pouze jednou za 10 let :-). Pokud největší ecommerce poskytovatel spoléhá na to, že má zřejmě veškerá uživatelská a produktová data v jedné obří databázi (lhostejno v kolika schématech a instancích), na kterou spoléhá, že nemá SPOF, je špatně něco někde jinde. Pokud se zastaví celá společnost díky výpadku jediné databáze, je to pravděpodobně jev. který má vést majitele k poznání, že současná vývojová cesta, přílišná agilita a obdobné řešení může společnosti způsobit nejen obří ztráty, ale i způsobit ztrátu reputace. Možná je čas na změnu, nejen architektury, ale i it organizace. Kdo z nás by nějaký výpadek Alza už na vlastní kůži nezažil. Zastaví se mobilní aplikace, sklady, logistika.....tramvaje. A peníze netečou!
Doufám, že to uvedené databázové architekty vede k úvaze, že se nevyplatí myslet izolovaně na úrovni jedné technologie, ale, že celé monolitická struktura řešení je špatná vize a je třeba navrhnout smysluplnou architekturu, což neznamená jen povýšit verzi programovacího jazyka.
Znam velke firmy, ktere nektere pomerne kriticke databaze maji take jen jednou. A to na zaklade racionalniho vypoctu nakladu selhani a nakladu na redundantni databazi. (Je fakt, ze zrovna tahle databaze nema primy dopad na klienty firmy, takze nasrani pri vypadku by byli hlavne zamestnanci.)
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).
