Reálný test si představuji trochu jinak a napsat testovací sadu je trochu složitější:
Rozhodně pro tento účel není vhodný scriptovací jazyk, ale jednoznačně například C++
Máte jistotu, že jste buď vždy převzal (fetch) data z SQL databáze, nebo že jste ji nechal přikaz udělat jen na prázdno?
Jaký typ indexu jste v PgSQL zvolil? A byl vhdný?
Operace na jedné tabulce a jen prosté SELECTY? Proč ne JOINy mezi tabulkami, výběry pomocí regulárních výrazů, subselecty, vkládání mazání a update ve vhodném poměru?
Takto to opravdu vypadá, že jste chtěl honorář a předvést, že nějaké databáze znáte.
IMO na konkurenčním serveru píšeme s kamarádem seriály o MySQL a PostgreSQL, do srovnání rychlosti se nehrneme a víme, proč to děláme ono stačí navrhnout testovací strukturu a indexy tak, že MySQL propadne o 500% i když tam bude jen 100 řádek.
hej? a aky je dovod pouzit prave C++?
dolezite je predsa, aby pre kazdy jazyk bola pouzita "ta spravna metoda".
ak to niekomu vadi ...
imho je jedno v akom jazyku sa vykona. kludne aj sposobom "time $console -f $file"
ak, tak testovat C/C++, Java, Perl, PHP, Python, mozno sa najde aj dakto, kto spominane testy napise v Ruby. ale samozrejme, vzdy aj cez konzolu daneho stroja.
dolezity je navrh testu. vypracuj(me/te) pre vopred zadany hw a sw
- konfiguraciu sluzby (spolu so startup skriptami
- navrh struktury tabuliek
- inicializacne data, postup inicializacie
- testy
pred kazdym testom reboot, spustenie len testovanej databazy.
testy:
a) priame vykonavanie SQL
- synteticke selekty
- cykly select - insert - update
- triggre, view, ...
b) s vyuzivanim roznych optimalizacii prace (prepare statementy, vypnuty autocommit, ...)
synteticky test je jednouzivatelsky
realny test je test pri pripojeni viacerych klientov (navrhujem testovat 8, 16, 32, 64, 128, samozrejme s moznou roznou optimalizaciou na predpokladanu zataz)
a spravit rovno "velky test" na
postgresql 7.4, 8.0, 8.1
mysql 4.0, 4.1, 5.0 (ak existuju dolezite dalsie verzie, doplnte)
firebird
(a vsetky mozne i nemozne dostupne db, ako oracle, db2, sybase)
priklanal by som sa k testu pod linuxom, s odporucanou konfiguraciou kernelu (2.4 / 2.6 by tiez stalo za uvahu do testu zahrnut).
samozrejme, vsetky nastavenia/utility/generatory atd pod GPL (alebo aspon LGPL).
do banku davam
- stroj pre domace pouzitie (p4 2,4; 512 ram; 200GB sata)
- svoje znalosti perlu a postgresql
Mno s pozadavkem na C++ jsem to mozna prepiskl, ale zase na druhou stranu je IMO lepsi kompilovany jazyk, nez scriptovaci (scriptovaci muze jet jako opravdu interpretovany, pripadne muze byt pri prvnim pruchodu interpretovany, ale dalsi prubehy cyklu mohou byt v jiz zkompilovane z cache..., anebo pred prvnim startem scriptu je docasne prelozen do strojoveho kodu a pak spusten, ...)
Ale zcela vazne, takto, jak bylo v tomto clanku test nema zadnou vypovidaci hodnotu, pouze vypovida o autorovi, ze si chtel vydelat a ukazat, ze zna nejakou databazi. (Nebo ze by redakce zverejnila clanek, pod nimz flame vyvola vetsi pocet zobrazeni reklamy, zamerne? :-D (Dobre, tak tomu sam neverim...))
btw: Reboot by nebyl potreba, ono by melo stacit zrestartovat daemona a je-li to v PHP i httpd, pak by v cache nemelo byt nic predzpracovaneho z minula.
I kdyz nejsem zastancem C++ s tim pozadavkem bych souhlasil. Tedy do te miry, ze by semlo pristupovat primo k API databaze (a nejcasteji je to C/C++). Jen tezko muzete hodnotit, jestli je rychlost spojena s databazi, nebo s implementaci ovladace pro DB.