Administrace komentářů

Databáze jako taková je portovatelná snadno kamkoli a proto jako normu můžu vzít jako normu její konkrétní implementaci SQL. Nijak mi to implementovatelnost na libovolný stroj (pokud to nebude 8bit atari) neovlivní. Nicméně i tak jsou sequence části normy SQL, takže jejich užívání normu neporušuji, ač tvrdíte opak.

POSIX normy se držím, protože vůbec nevím, jakej má tazatel systém (a když budu chtít řešení přesunout, tak to s proprietálním přepínači půjde těžko). Pokud na jeho systému mv -n mít nebude, tak si tam těžko bude portovat jinou implementaci. Třeba solaris mv má v určitých drobnostech jiné chování než GNU, takže instalací GNU mv si člověk může zadělat na pěkné problémy. Samozřejmě: vše je řešitelné. Jen je otázka za jak dlouho a s jakým rizikem chyby.

---

Posloupnost příkazů? To se fakt chceš až tak ztrapnit až tak, že nevíš, že operace nad sekvencema je by definition nezávislá na transakcích? Takže třeba:

SELECT NEXT VALUE FOR moje_sequence ;
INSERT INTO tabulka (id, ...) VALUES (*ziskane_id*)

anebo (tady pro postgresql)

INSERT INTO tabulka (...) VALUES ();
SELECT curval(moje_sequence);

a taky to nebude trpět chorobou z konkurečního přístupu, i když to neudělám v transakci. Překvápko, co? Vidím, že fakt "umíš". (sorry za sarkasmus, ale todle fakt nejde, normální člověk dřív, než něco takhle opakovaně tvrdí, tak si to aspoň zkontroluje, že to tak opravdu je, jinak je za blbce).

A navíc v každé db je funkce na zjištění ID vloženého záznamu (LAST_INSERT_ID v Mysql, RETURNING clause v Postgresql, Oracle, Firebird), takže těch cest je X a pokud neudělám select zpět na tabulku (což je ta úplně nejhloupější cesta a navíc nesmyslná, protože select má smysl pouze pokud umím záznam identifikovat a pak to ID vlastně ani nepotřebuju), tak transakci nepotřebuje snad žádná.

---

Vzhledem k tomu, že o vstupu nic konkrétního nevíme, tak je normální předpokládat, že je korektní (předpokládal to i Tvůj kolega).

A ano, analyzátor může začít zpracovávat soubor vzniklý z korektního vstupu dříve, než ho v příkladu prezentované řešení pomocí cat zapíše celý, zatímco v databázi se to opravdu stát nemůže.

Atomicita je přesně daný termín, pokud se bavíte o takovýchto věcech a nevíte co to znamená, tak no comment. Tak si to přečtěte na wiki. Operace nad databází (pokud nepoužívají externí funkce přistupující jinam, ale to už pak není čistě DB operace) jsou atomické vždy z definice, nikoli pouze někdy, jak tvrdíte. To Ti už dokládat nebudu, už mě to nebaví, nechám to Tvému samostudiu.