Administrace komentářů

Hromadný/dávkový způsob je, že napíšu jeden příkaz a ono to něco udělá s hromadou záznamů. Přečti si na wiki definici dávkového zpracování: "všechna data jsou připravena předem a pak se vykoná program". Nikde není napsáno, že to znamená, že se se všemi záznamy provádí stejná operace, nebo jak jsou záznamy, nad kterými je provedena dávka identifikované. Pro debatu o odborné problematice to chce znát terminologii.

Když to uděláte podle primárních klíčů, je to přesně to rozepsání každého UPDATU na dvojici DELETE+INSERT

Není, protože relační databáze jsou dělané na hromadné změny dat. Zapsáním do jednoho dotazu se ušetří spousta času, protože velká část činností se bude muset dělat jen jednou (parsování dotazu, optimalizace, zamykání datových struktur etc...) a navíc bude moci databáze zvolit optimální plán na získání těch záznamů, než když se to dělá po jednom, čímž se dostáváme k další věci, ve které nemáš pravdu.

Pokud mám delete where id IN (...) a pak delete where id in () and něco between něco and něco, tak je druhý dotaz může být (dle rozložení dat a statistik) rychlejší, protože je intervalový. Tzn. v prvním dotazu databáze neví, které jsou a pro každý udělá extra lookup do indexu. Pokud bude těch idček hodně, tak dokonce zvolí sekvenční přístup nebo nějaký hash-join. Pokud tam ovšem bude druhá intervalová podmínka tak si místo toho databáze může jedním dotazem do indexu zjistit patřičné bloky a v nich pak už jen sekvenčně zkontrolovat idčka. Pokud nevěříš, tak si to zkus na nějakejch rozumnejch datech udělat explain plánů, že jsou opravdu jiné, což ukazuje na to, že pro databázi je výhodnější to hledat dle té intervalové podmínky. Samozřejmě závisí na tom, jak velkou část z toho intervalu chci: ale to je přesně to "nech to na db".

--

Proč má záznam v databázi unikátní ID? Třeba proto, aby byl jednoduchý primární klíč. A ze spousty jiných důvodů (např. standardní zpracování ORM nástroji či nástroji na generování dotazů atd. atd.). Navíc: já jsem někde psal, že tam musím mít idčka? To, že tam musím mít idčka je opět vaše projekce. Zas polemizujete sám se sebou.

Takže pokud uživatel upraví 100 záznamů a v 1 bude konflikt, hodíte mu zpátky na hlavu 100 záznamů, ať si ten konflikt najde ručně? To budete dostávat tisíce děkovných dopisů…

Ano, hodím. Napíšu mu: v databázi se stala oproti editaci taková a taková změna (to vyslektím opět jedním dotazem), tyto dni zmizely, tyto se objevili. Opravdu chcete vložit těchto sto záznamů a ostatní smazat? Když uživatel pracuje s množinou záznamů, tak je neslušné ho nechat půlku množiny uložit a půlku ne. Je na něm, jestli bude řešit jen ten konflikt, nebo na ten konflikt zareaguje úpravou celé množiny, proč mám být chytřejší než on.

Co je id_verze?

To už jsem psal? To musím každou věc napsat desetkrát? Id verze je id verze, tzn. číslo, které se po každé změně mění a je unikátní v db. Tedy např. je na tabulce before insert or update trigger NEW.id_verze = nextval('table_verze_seq')

Ale hlavně, uživatel nebude mít žádnou možnost upravovat, jenom přidávat a mazat

Takže jen kvůli tomu, abych dostál svému programovacímu purismu, že něco je set, tak místo toho, aby když se člověk při zadávání splete, tak danou položku přepsal, tak ji musí smazat a nahrát jinou. Ještě že nevyvíjíš aplikace pro mě.

/příklad/

Tak zaprvé jsem psal, že budu mít id verze sdílené, takže ten příklad nevyhovuje. Ale to je detail, protože

Neupravené záznamy ani uživatel nikam neodesílá, bylo by to jen plýtvání.

...jste totálně překroutil zadání. Vždyť tazatel přímo píše: "ale bolo by to podla mna narocnejsie kazdy jeden zaznam skontrolovat a nasledne updatovat alebo neupdatovat.". Takže dle zadání NEVÍTE, co bylo nebo nebylo upraveno, smazáno atd uživatel odesílá celou množinu a pokud to chcete vědět, musel byste to u každého záznamu zjistit (= skontrolovat, neumíte-li slovensky). Holt když celá vaše kritika vyplývá z toho, že si ani neumíte pořádně přečíst zadání....