SQL uganka

-- setup
create table test (a number, b number , c number /* primary key */ );

-- tole napolni tabelo s podatki za test, z 500000 vrsticami (OK, ena manj)
insert into test select 0,0,level from dual connect by level<500000;
update test set b=99 where mod(c , 2)  = 0; -- tole bi lahko v zgornji INSERT stlačili...

         A          B     C
---------- ---------- ----------
         0          0     1
         0         99     2
         0          0     3
         0         99     4
         0          0     5
         0         99     6
itd...

update test set a=1 where b=0;

update test set a=1 where c in (select c from test where b=0);

Utisevalec je včeraj ob 18:43:07 izjavil:

Povedat moraš tudi frekvenco in zaporedje ukazov.

Utisevalec je včeraj ob 18:43:07 izjavil:

Zgornja dva ukaza niti priblizno nista ista v izvedenem zaporedju

Lahko izvedeš enega, ali drugega. A je rezultat v obeh primerih enak?

update test set a=2, b=2 where c between 300000 and 400000;

         A          B
---------- ----------
         1          2

Utisevalec je včeraj ob 19:54:20 izjavil:

Kot sem rekel, v transakcijski DB je pomembno zaporedje ukazov. SQL bo desni ukaz vedno izvajal pred levim (SELECT pred INSERT). A izvede admin nek ukaz prej ali pa se izvedejo zapisi vmes je enako. Sicer klasičen catch22 pri teh SQL ukazih imaš v izvajanju linearne kode, kjer hitro dobiš real-life bug (vzemi neko JS "ajax" kodo pa jo izvajaj po koncetu nesinhronosti pa dobiš to kar rabiš za bug).

Utisevalec je včeraj ob 19:12:14 izjavil:

Če smatraš SQL bazo kot transakcijsko, potem ukaza nista enaka, ker se tisti SELECT vedno izvede prej (vmes imaš lahko nafilanih 100 vrstic kjer B == 0 in jih ne bo zajetih v SELECT stavku, bi pa bile v prvem primeru). Če govorimo o 10 updejtih na uro sta pa stavka enaka.