Administrace komentářů

Pokud se uživatel pokusí vložit duplicitní záznam do unikátního indexu, je správné oznámit mu chybu a nechat jej problém vyřešit. Pokud by to byla datová struktura set, bude unikátní index zároveň primárním klíčem, použiju SQL příkaz REPLACE a je to vyřešené automaticky.

Já nikdy netvrdil, že nebudu potřebovat podmínky na verzi, jen že se to dá napsat jedním dotazem. … Stejnětak není pravda, že jsem někdy uvažoval DELETE+INSERT po jednom

Poslyšte, nemohl byste si vybrat. Takhle se popřít hned v následujícím odstavci, to není hezké. Takže – budete záznamy mazat hromadným DELETEm s podmínkou bez IDček, nebo je budete mazat po jednom, tj. v podmínce budou IDčka?

jen že se to dá napsat jedním dotazem

No a co? To nikoho nezajímá.

stejně jako ty tvrdíš, že ta oprava těch X chyb, co jsem našel v Tvém algoritmu

X = 0

mj. hromadný delete jde i podle id

V tom případě netuším, co si představujete pod hromadným DELETEm. Já si pod tím představuju právě to, že podmínka popisuje množinu záznamů podle dat, ne podle primárních klíčů. 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.

pokud tam doplním druhou intervalovou podmínku, tak to bude řádově efektivnější než X samostatných delete

Pokud k DELETE podle ID doplníte druhou podmínku, bude to nanejvýš pomalejší, než DELETE jen podle IDček.

Tady se snažíš dokázat že máš pravdu tím, že změníš zadání: my tady prostě závislá data nemáme (pokud ano, musel bys považovat autora dotazu za idiota, že vůbec DELETE+INSERT uvažuje - což vzhledem k tomu jak diskutuješ Ti asi nedělá problém? Tak co, považuješ autora dotazu za idiota?).

Proč teda každý záznam v databázi má unikátní ID? Pokud má jít jen o tabulku, která pro uživatele eviduje seznam dnů, stačí dvojice uživatel+den, to celé v primárním klíči. Navíc pak je to obyčejná množina (set), která má jen operace přidání a smazání, aktualizace nemá smysl řešit.

Ty prostě místo toho, aby jsi se pořádně zamyslel nad tím, jaké je zadání a co píšou ostatní

Já jsem se zamyslel. Ale takhle se nezamyslet, jak se to podařilo vám – nepochopit zadání, práci uživatelů, algoritmy ani sám sebe – to se jen tak někomu nepovede.

DELETE FROM tabulka WHERE podminka AND verze NOT IN (...id_verze...)

Co je id_verze?

if(počet smazaných < počet editovaných) then ROLLBACK

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ů…

A protože furt píšeš, že můj algoritmus nejde použít, tak prosím:

Dobře. Uživatel ukládá tyto změny:

smazáno:
id=1, verze=1
id=3, verze=2
upraveno:
id=2, verze=1, datum=A
id=4, verze=2, datum=B
přidáno:
datum=C
datum=D

Jak bude vypadat posloupnost SQL příkazů, které zavoláte? Jak budete testovat návratové hodnoty (počty změněných řádků)? Ideálně když to popíšete jako v předchozím komentáři v nějakém pseudoPL/SQL, ale s dosazenými hodnotami parametrů.

Copak ty také neděláš update na všechny záznamy?

Proč bych to dělal? Dělám update na ty záznamy, které uživatel upravil. Neupravené záznamy ani uživatel nikam neodesílá, bylo by to jen plýtvání.

Opakuji: v tomto threadu šlo o to, zdali je lepší přístup po řádcích, nebo dávkový

Už jste si rozmyslel, který přístup zastáváte? V druhém odstavci jste byl pro přístup podle IDček (po řádcích), ve třetím pro dávkový…

Todle totiž principiálně nejde řešit bez operací, která porovnává data a modifikuje jen opravdu změněné záznamy.

Změněné záznamy se poznají podle toho, že je uživatel změnil. Tedy přepsal nějakou hodnotu a potvrdil ji, otevřel editační režim a uložil změny nebo něco takového. Koukáním na výpis se záznamy nemění.

Ad 28.4. - Pokud to bude model, kdy je možno více schůzek jeden den, pak ovšem musí být ty schůzky rozlišené a tedy jde opět o jiný případ než co řešíme zde: je-li datum klíč, pak v našem případě jde o implementaci datové struktury set, zatímco v tamté multiset. A světe div se, různé datové struktury se upravují různými algoritmy. Jinými slovy, další příklad, kde jsi upravil zadání, abys dokázal svoji pravdu.

Pokud jde o datovou strukturu set, bude unikátní index na dvojici uživatel, datum. Ale hlavně, uživatel nebude mít žádnou možnost upravovat, jenom přidávat a mazat. Protože v datové struktuře set nikdo nic upravovat nechce, a normální člověk si ani nepředstaví, co by to znamenalo.