Administrace komentářů

Standardní postup je takový, který odpovídá standardům a minimalizuje riziko chyby. Obojí postup z MySQL nesplňuje (byť ta chyba může vzniknout úplně jinak, než co jsi se snažil ukázat).

Dokud se při zakládání souboru nepoužívá VŽDY metoda vytvoř dočasný soubor a atomicky přesuň, je situace naprosto nesrovnatelná, protože výše zmíněné chyby se evidentně dopustí člověk snadno, zatímco tvojí prasečinu s ID rozumnej člověk neudělá. Rozdíl je vidět i v tom, že zatímco chybu s cat > nejde jednoduše objevit, člověk se nad tím musí zamyslet, tak Tvojí prasečinu s ID lze detekovat primitivní statickou analýzou zdrojového kódu.

K poslednímu odstavci se dá říci toto: směšuješ transakční zpracování a atomicitu, jde o dvě věcí: databáze má atomické operace i bez použití transakcí. Nikdo neříká, že databáze Ti zařídí transakce sama od sebe, pouze atomické čtení a zápis. O transakci musíš explicitně požádat a ta má své limity.

U FS je to ale daleko horší, ten nemá transakce vůbec a o atomicitu musíš explicitně požádat (vybrat správný způsob provedení dané operace). Navíc narozdíl od DB lze požádat pouze ve speciálních případech (zatímco v DB je každá jednotlivá operace atomická automaticky) a proto se narozdíl od DB, kde používání transakcí patří ke slušnému chování, atomicita často stojí výkon navíc a proto se standardně nevyžaduje.

Proto je FS v tomto ohledu daleko horší a méně user friendly: něco tam nejde (některé atomické operace, transakce) a vzhledem častému k používání neatomických operací člověk běžně atomicitu neřeší a proto ji pak neřeší ani tam, co má. V DB člověk bez ztráty výkonu má nejen atomicitu, ale i transakce a je standardem je používat. Pokud neřeším atomicitu ve FS, mám na 99% průšvih. Pokud v DB a nepíšu jako prase, málokdy to způsobí problém.