To je rozhodne zajimavejsi srovnani nez ten prvni clanek.
Asi by bylo zajimave (ale taky pracne) prirpavit ruznych testovacich selectu vice a pak se podivat na variabilitu namerenych casu v zavislosti na databazi (nebo spis databazi a platforme)
Cim kvalitnejsi a robustnejsi databaze, tim vyrovnanejsi vysledky by mela podavat (nezavisle na charakteru dotazu si s nim v rozumnem case poradi), zatimco horsi databaze sice nektere dotazy zmakne bleskove, ale na jinych si vylame zuby.
Pochopitelne je vyhoda, kdyz pri vyvoji aplikace nemusite dumat, jak dotaz prepsat, abyste databazi neposlali do kolen. (navic, jak je v clanku popsano, casto se vyvoj dela na malych datech, kde se nic neprojevi a v provozu to pak skripe; u horsich databazi je pak toto riziko vetsi)
Kdyz si seradim databaze podle smerodatne odchylky jednotlivych mereni (predpokladam, je to cas provadeni dotazu), na linuxu mi vychazi poradi (berte hodne s rezervou, tech testu by to chtelo vic a jeste k tomu by to chtelo, aby jednotlive testy byly srovnatelne v narocnosti, aby variabilita vysledku nebyla primarne dana tim, ze jeden test bezi v prumeru 10s, zatimco jiny 0.01s)
Tak nejak, tri truhy dotazu jsou hrozne malo, i kdyz to urcitou malou vypovidaci hodnotu ma. U mne to byl ve vsech pripadech 4xJOIN, 1 test AND, 1 test OR. Tech dimenzi muze byt vic: dostupna pamet, pocet procesuru /pocet klientu, pocet radku. Urcity ukazatel kvality je take neexistece singularit, tj. napr. vykon dramaticky spadne po vycerpani RAM, pri prekroceni urciteho poctu radku, ... No proste tema na slusnou diplomku.