Jestli treba MySQL neztrati jen par % zaznamu treba proto, ze uz jich vetsina lezela na disku uz pred crashem, protoze uz to byly stare zaznamy.
Anebo MySQL dela nekdy taky fsync(), coz u testovacich programu nevime.
Fakt tezko rict, co si z tohoto clanku vzit, ze zminky, ze DB4.1 precetla 571 zaznamu ze 70000 se da odhadovat, ze se pracovalo se 70000 zaznamy, jestli se nacitaly nebo menily ...
Pokud pouzivas funkce read a write (pochopitelne, fprintf je neco jineho), pak jsou buffery pouze v kernelu. To znamena, ze i kdyz aplikaci zabijes kill -9 (o mene agresivnich zpusobech nemluve), budou data zapsana, at uz volala fsync nebo ne. Funkce jako fsync chrani pred havarii OS nebo HW (napr. vypadek proudu).
a) Na "*((type *) 0x00) = val;" neni nic nelegalniho, nevidim duvod proc
by si mel kompilator stezovat.
b) Nevim proc chvalit knihovny za to, ze se opovazuji osetrovat signaly do
kterych jim nic neni. To je naopak dost negativni vlastnost.
c) Nechapu pointu clanku. U techto typu databazi se preci _pozaduje_ aby
je uzivatel po pouziti korektne zavrel. Pokud to neudelate, prijdete
o data -- a co? Je to jako stezovat si ze nemuzu precist CD ktere jsem
behem vypalovani vyrval z mechaniky.
d) Tohle je trochu mimo, ale jazykova uroven clanku je mizerna. Zni to jako
doslovny preklad z anglictiny.
ad c)
To teda nejste noc náročnej. Když použiju embeded db, chci od ní 1) stabilitu 2) rychlost 3) jednoduchost
Např. SAMBA ukládá konta a hesla do tdb. Uživatele si je občas mění, jsou tam ukládany stavová informace. Díky chybicce mi nedávno samba padala pri tisku, pri představě, nasledné havárie databáze kont se mi po vašem výroku (U techto typu databazi se preci _pozaduje_ aby je uzivatel po pouziti korektne zavrel) otevirá kudla v kapse