petersveter:
sorry, ale co je nepochopitelného na tom, že
- MySQL má v určitých specifických workloadech větší výkon (viz Pavel Stěhule)
- set featur MySQL není podmnožinou setu featur PostgreSQL
- ale že 99% (a spíš ještě o pár devítek více) vývojářů se s implementací, kde by to, že PostgreSQL je v daném workloadu nedostatečně výkonná, nebo že neimplementuje danou featuru, nikdy v reálu nepotká (např. já si myslím, že už jsem nějaké i poměrně komplexní systémy dělal, a k limitům Postgresky jsme se nepřiblížili asi nikdy). Takže sice je dobré o tom vědět, ale to nic nemění na tom, že je rozumný přístup prostě používat Postgres, a MySQL uvažovat jako možné řešení jen v (čistě teoretickém) případě, že narazíš na limity Postgres (což nenarazíš) - s tím, že většinou pak stejně je rozumější to udělat jinak (např. nasadit Redis nebo něco podobného a do SQL jen agregovat).
jjrsk:
- No já jsem čistě polemizoval s Tvým "databáze musí umět" v kontextu toho, co jsme řešili. Tam jsi psal nejen o MySQL, ale i o "normální databázi" :-)
- Jinak ano, může to být možný přístup. Ale vzhledem k tomu, že každá záloha má smysl, jen když je nějak natrénováno obnovení, takže na rozumné implementaci záloh tak jako tak spálíš nějaký čas, tak už zas nevidím důvod, proč nepoužít např. ty WAL logy a neztratit, pokud je to možné, nic.
Nastavit to zálohování dle manuálu na pokusném stroji není zas tak "hardcore", aby se to nedalo, a zkrátí to podstatně dobu obnovy (nemusíš hledat snapshot, který "se povedl", máš přesně definovaný postup obnovy). Samozřejmě to jsme zas u toho, že když máš MySQL, tak to (asi?) nejde - ale to je přesně důvod, proč doporučuju PostgreSQL: místo vymejšlení partizánskejch postupů, jak obejít nestandardnosti MySQL my přijde rozumnější nevymejšlet kolo, ale udělat to tak, jak se má, s nástrojem, který je na to vhodný. Ve výsledku člověk ušetří nervy i čas.