vo vsetkych tabulkach je * po dodatocnom pridani indexov. Ale akych indexov. Moze autor pridat sql prikazy pre vytvorenie indexov, pretoze by to pomohlo aj ostatnym, aby si pozreli, ze ktore indexy su vhodne, ktore nie.
V textu byla nepatrna poznamka: mysql a firebird pri definovani referencni integrity REFERENCES tab () vytvori index i nad sloupcem obsahujici cizi klic. PostgreSQL tento index 100% nedela, a pokud jsem se nespletl (preci Oracle a MsSQL neznam tak do hloubky, takze nejakeho systemoveho indexu bych si treba nevsiml) tak Oracle s MsSQL take ne. Diky tomu, pokud mate libovolny priklad obsahujici referencni integritu, tak my. a fi. maji jeden index navic a v porovnani dosahuji lepsich vysledku. Pokud tenhle chybejici index pridate do PostgreSQL, tak ma lepsi vysledky PostgreSQL. Takze, aby ta cisla byla alespon trochu porovnatelna pridaval jsem rucne indexy na sloupce obsahujici cizi klice std. prikazem
To je ale spatny predpoklad. Pouziti indexu nemusi vzdy zrychlit dotaz a naopak jej muze i pekne zpomalit, protoze jeho pouziti je nadbytecne. Mam takovou zkusenost prave s FB, kde preferuji udrzovani referencni integrity pomoci triggeru a volitelne indexu prave proto, ze vytvari pro FKs indexy a pouziva je v selectech, kdyz by bylo sekvencni zpracovani rychlejsi. Jak by to dopadlo bez indexu na FK?
A jedna velka vytka za me k clanku - chybi mi velmi plany jednotlivych dbms pro jednotlive selecty.
Dobra, sekvencni cteni bude rychlejsi cca do 100(0) radku. Jelikoz 3 ze 4 tabulek maji nad 10000 radku, tak sekvencni cteni asi nebude to nejrychlejsi. Testoval jsem Firebird2, ktery ma lepsi optimalizaci dotazu, priznam se, ze plan jsem zas az tak dukladne nesledoval. Nicmene prave ze jsem importoval bez indexu, tak jsem importoval i bez referencni integrity, a somosebou jsem byl liny nastovovat ref. integritu, poprve jsem nastavil jen indexy. Casy Fb. byly zhruba kolem 10 sec, tedy o dost vic nez u ostatnich databazi. Fb. sekvencne cetl tabulku faktura tusim - proste kaslal na primarni index. Takze jsem si dal praci a nastavil ref. integritu, coz melo zasadni ucinek. Takze mozna presnejsi tvrzeni - pokud ma tabulka nad tisic radku, tak index nad cizim klicem pravdepodobne urychli dotaz. Ty indexy jsem u firebirdu zkousel celkem dost, prave protoze mne prekvapilo, jaky to ma zasadni vliv na vykon. Pomohl index i u tabulky produkty, ktera ma 250 radku.
Plany jsem mohl pribalit, pravda. V okamziku, kdy jsem s Fb. dosahoval podobnych casu jako u ostatnich db. jsem se s tim dal nezabyval. Generujici zdrojak mate, tak portnete s.p. do fb, a vygenerujte si jej.