Tak zajima me to prave z architektonickeho hlediska, protoze pripravuji prepsani sveho erp/ucetnictvi (inhouse reseni). At to je cely vlastne primarne insert-only (writeonly, append), a modify se dela jen nad pomocnymi tabulkami pro aktualni stav (primarne z toho duvodu aby to bylo zivy a synchronni ve dvou lokacich). Nejvetsi hruza je ale ze zmen schematu - doposud na te "primitivni" db bylo vse jenom rozsirovano a pridavano, s tim ze to je pak zpetne kompatibilni (tj. nic nezmizi a ani nic nebude jinak), ale pak to casem vytvori neudrzovatelny moloch (asi hodne SAPoidni).
Tak se pidim po tom, jak resit tyhle veci (tj. nejake procesni pristupy, at je schema synchronni s okolnimi "skripty"). Napada me takovej tick-tock pristup, kdy se prvne zmigruje okoli na pouziti obojiho a pak az data. A to jeste bych rad bezvypadkove (treba aukro me neskutecne vytaci hlaskou o odstavce.. tohle v roce 2025 by uz nemelo byt bezne/caste). Z popisu jak hodnotis sektor by me byl blizsi asi pristup vice mensich zmen, ve smyslu mala zmena = mensi sance to podelat, castejsi zmena = stane se z toho rutina, nez ten druhy obcasny s vetsimi upravami.
Udělej mezi tím rozhraní, pohledy, marty, jinou databázi.
Přistup k schématu a databázi jako k vlastnictví. Každé scéma vlastní konkrétní aplikace a nikdo jiný než daná aplikace dané schéma nepoužívá. Pokud potřebuješ data sdílet mezi aplikacemi, exportuj data jako veřejný, stabilní, zaručený interface (ať už formou materializovaných pohledů nebo replikaci do jiné databáze nebo použití nějaké rpc nebo fronty), pak máš prostor, kde můžeš ošetřovat zpětnou kompatilibitu, verzovat či řídit změny bez ohledu na to, jak s schématy zachází její vlastník.
To, jestli jedna aplikace bude celý ERP nebo tam budeš mít jednotlivé služby je na tobě, vždy se při určité velikosti vyplatí to logicky rozdělit.
A pokud jde o řízení změn u konzumentů dat, tak hodně záleží na tom, co konzument dělá. Pokud to je třeba posílač emailů, tak starého omezím pouze na původní verzi schématu a spustím nového nad novým schématem. Stará data doběhnou a nové se začnou posílat jinak.
Nebo udělám nějaký bridge, který bude nové schéma zpětně migrovat do starého, aby původní aplikace plně fungovala beze změn. Tohle je třeba v případě bank častý způsob. Navenek nic není vidět. Až aplikace se upraví, změní se jí link na nové schéma a bude ho konzumovat přímo.
Základem je ale pořád mít nějakou vrstvu, která bude fungovat jako mezičlánek, výstup z té vrstvy je verzovaný interface a o vstup se právě stará majitel schématu a udržuje migrace při změnách. Na začátku třeba začínáš tím, že máš pohledy typu select *, protože nepotřebuješ nic jiného dělat.
Pokud jde o zápis, platí pravidlo výše, pouze jedna aplikace jako vlastník může do schématu zapisovat, ostatní nikoliv, takže na vše mít RPC nebo frontu změn a ty si bude sama aplikace odbavovat, jen ta ví, jaké je správné schéma. Varianta, kdy všichni zapisují do jedné společné databáze, jak je běžně vidět u webových aplikací vede pouze a jen k celkovým odstávkách při aktualizaci.
Pokud jde o bezvýpadkovou aktualizaci a migraci schémat. Buď máš potřebnou obslužnou logiku implementovanou v aplikaci a v jednu dobu zapisuje a čte z dvou různých verzí schémat, což je někdy dost komplikované nebo používáš materializované pohledy a migrace na úrovni databáze, aplikace pak má najednou k dispozici obě verze schémat, nové i staré a může postupně přejít na nové.
Občas se dostaneš do situace, kdy změnu potřebuješ udělat daleko rozsáhlejší, použij verzování route a směruj staré požadavky na starou aplikaci a nové požadavky na novou a v jednu dobu budeš provozovat dvě verze backendu, data z nich sdružovat právě v nějakých martech, veřejných interfaces.
Cest je ale hodně, tohle je jen takové postrčení jak to můžeš řešit. Vše zmíněné zvládne pg, s mariadb nepočítej. Pokud se vzhlédneš v moderních nosql databázích, budeš si to muset nějak implementovat sám.
Poslední příspěvky
