Administrace komentářů

- Děláš machra, ale např. v MVCC architekturách databází je každej update v podstatě úplně totéž co delete a insert (tzn. postgresql, oracle, firebird).

- U neMVCC databází jsou většinou data uložená clustrovaná dle primárního klíče (či jiného daného indexu). V tu chvíli záznamy prostě nebudou fragmentovány. Pokud by už k fragmentaci došlo, tak nikoli na provni záznamů, ale stránek: tady je pak naopak větší šance, že při DELETE a následném INSERTU budou stránky, ve kterých leží vkládaná data u sebe. Naopak pokud půlku záznamů oupdatujeme a druhou vložíme nově, tak se riskuje fragmentace více.

- UPDATE spojený se SELECTEM query optimizer vyoptimalizuje úplně stejně, jako DELETE a INSERT. To, o co jde je počet diskových operací a každá databáze si po DELETE natáhne patřičnou stránky do paměti, takže následnej insert je v podstatě zadarmo. Výhoda UPDATE oproti INSERT/DELETE je v tom, že se nemusí dvakrát zbytečně upravovat indexy.

- REPLACE je defakto cukr pro DELETE a INSERT. To ušetří v podstatě jen čas na kompilaci dotazu.

- Vyhledávání po jednom při hodně záznamech opravdu blbé je: nikoli kvůli scrollování (to se musí u mazání dělat taky), ale pokud je těch záznamů více, tak kvůli komunikaci s DB a kompilaci mnoha dotazů a komunikaci s db. Řešení s INSERT ON DUPLICATE ROW UPDATE sice vhodné je, ale jen pro malý počet řádků. Pro větší počet řádků se může chovat hůře, než jeden příkaz INSERT a jeden DELETE: ty bude levně chroustat nad pár datovými stránkami. Pokud se takovéto řešení použije, tak je třeba nejprve nové dát do dočasné tabulky a pak tabulku opravit jedním DELETEM a jedním INSERT ON DUPLICATE ROW UPDATE.

- Poslední Tvé tvrzení IMHO není pravda (už proto, že na těch tabulkách mohou být pověšené triggery, on update current timestamp a podobná zvířátka)

- Když to tak po sobě čtu, Tak bych měl i pro Tebe jednu radu. Připraven? Tvoje rada tazateli platí i Tobě.