Administrace komentářů

Váš algoritmus verzování nemá, hromadný DELETE bez podmínky na jednotlivá ID nejde s verzováním rozumně použít. Odolnost proti konkurenčním updatům považuju za samozřejmou, to není žádná extra vlastnost navíc, kterou by bylo potřeba v zadání zmiňovat. S verzováním jsem počítal od začátku, proto mne taky ani nenapadlo navrhovat nějaký algoritmus s hromadným mazáním.

Postupy jsou tu tři. UPDATE, hromadný DELETE + INSERTy a DELETE+INSERT po jednotlivých záznamech. Vy mezi druhým a třetím řešením volně přepínáte -- když tvrdíte, že to řešení umí verzování, mluvíte o třetím případu, když o tom, že je to méně operací, mluvíte o druhém. Pokud už jste tedy dospěl k tomu, že druhý algoritmus nejde použít a je potřeba použít třetí, uvědomte si, že tam aktualizaci každého řádku přepisujete z UPDATEu na dva příkazy DELETE+INSERT. A zamyslete se nad tím, zda a k čemu je takový přepis užitečný.

Detekce počtu ovlivněných řádků logicky není ve výpisu SQL příkazů uvedena, protože ji dělá aplikace. Není potřeba to explicitně psát, protože každý, kdo má aspoň základní zkušenost s databázemi a někdy optimistické zamykání s verzováním záznamů psal ví, jak to bude vypadat.

Fungovat to bude. Pokud si myslíte, že ne, napište nějaký příklad, kdy to fungovat nebude. Při tom prosím nezapomeňte na unikátní indexy, jako se vám to stalo v předchozím příspěvku.

V přístupu, kdy jeden UPDATE nahradíte dvojicí DELETE+INSERT konzistenci samozřejmě zaručit lze, protože když ty dva příkazy uzavřete do izolované transakce a v databázi nebudou na těchto záznamech žádné závislosti, bude výsledek identický, jako s jednoduchým UPDATEm (to ale neplatí o způsob provedení). Akorát jste nevysvětlil, jaký smysl by mělo nahradit jeden příkaz dvěma a skrýt před databází informaci, kterou by mohla použít pro optimalizaci.

Ano, pořád jsem přesvědčený, že nejde napsat algoritmus, který bude používat hromadný DELETE (ne podle primárního klíče), který bude verzovat jednotlivé záznamy, nebude porovnávat obsah záznamu a nebude hlásit falešné poplachy (tj. konflikt na řádku, který nikdo neupravil). Problém totiž není v tom verzování (tam se dá použít sdílená sekvence nebo čas změny záznamu), ale v tom hromadném mazání. To totiž smaže a znovu vytvoří (= nová verze) i záznamy, které uživatel nijak nezměnil.

Normální člověk nepozná, že schůzka 24.8. je schůzka 24.8. Normální člověk před sebou vidí kalendář, kde má barevné obdélníčky, a ty znamenají schůzky. Na 24.8. může mít v kalendáři x různých schůzek. Normální člověk taky ví, že když ten obdélníček bafne myší a přetáhne jinam, změní se datum a čas schůzky, ale bude to pořád tatáž schůzka (a zůstanou u ní informace jako kancelář, pozvaní lidé, poznámky apod.). Zatímco když tu schůzku smaže a vytvoří jinou, bude to jiná schůzka, která s původní nebude mít nic společného. A bude tam muset znovu zadat kancelář, pozvané kolegy, poznámku, popis…

Váš příklad se smazáním a vložením toho samého záznamu platí jen v případě, kdy daná tabulka nemá žádné vazby. Což je případ velmi ojedinělý – a je pak otázka, proč vůbec chcete používat SQL databázi.

Dobře, v příkladu je id záznamu určeno pozicí. Takže si to převedeme na něco reálného – na začátku mám v bedýnce 1 cibuli a v bedýnce 2 datle. Pak přijde Adam, z bedýnky 1 vysype cibuli a dá tam ananas, z bedýnky 2 vysype datle a dá tam cibuli a přidá bedýnku 3, do které dá estragon. Zároveň přijde Bára, z bedýnky 2 vysype datle a dá tam ananas a přidá bedýnku 3, do která dá estragon. Když se to pokusí udělat druhý z nich, dojde ke konfliktu v bedýnkách 1 a 2, který bude muset vyřešit. Takže Adam nebo Bára rozhodnou o tom, která varianta je správně – zda A, C, E nebo C, A, E.