MySQL-3.23.21-beta a BerkeleyDB tables

Karel Zak zakkr na zf.jcu.cz
Sobota Červenec 15 14:07:38 CEST 2000


 
 Zdar,

>    >  To mne napada otazka --- pokud jsi se dival na zdrojaky PG a MySQL, mas
>    > nejaky "porovnavajici pocit" z teto oblasti?
> 
> tvrzení o tom, že jim někdo ukáže kód a oni jej zařadí. Tady je prostě
> napadlo, že transakce jsou fakt potřeba a začali je implementovat. Alespoň
> mi to tak připadá. Nebo se pletu?

 To byl i muj pocit i kdyz to nesleduji :-)

> Nevím, jestli jsem ten správný, ale myslím si to, co napsal Ondřej - nikdo
> Ti neříká, že si musíš zvolit pro každou tabulku ten typ, který toho umí
> nejvíc. To si myslím, je nyní velká přednost MySQL. Např. pokud chceš velmi
> rychlé tabulky (např. TEMP tables), zvolíš velmi rychlý typ tabulky HEAP,
> která je uložena kompletně celá v paměti, vůbec ne na disku. Pokud chceš
> normální tabulku (s možností recovery), použiješ MyISAM. Pokud potřebuješ i
> transakce, tak zvolíš typ BDB (doporučuji to udělat až v další verzi :-)).

 Nevim, ale vetsina DB kde jsou transakce jsou tim prolezle uplne cele a
nejde jen o soubory.. i kdyz uznavam, ze to ze strany MySQL je zajimava
vlastnost.

>    > select 1 from hesla where uzivatel = 'adelton' and heslo = 'zakryptovaneheslo'
> 
> No, tak zrovna tohle kdybych měl dělat hodně rychle/často, bych nepoužil
> databázi :-) A pokud bych musel, tak bych si napsal novou funkci v C a
> přilinkoval.

Todle byl asi nepovedeny priklad. Ono jde hlavne o usetreni casu stravenem
na parseru coz je napr. u PG hodne casu protze vse je dynamicke a taha se ze
systemovych tabulek. Napr. pokud mas nedatovy dotaz (nic nehledas na disku)

select 'Pavel ' || ' uz konecne ' || ' pouziva PostreSQL' as cool;

tak nacacheovanim parsovanych struktur lze dosahnout az urychleni o 94% (to
je overene cislo :-), coz by mohlo byt lepsi ale i tak to neni spatne... :-)

> Tohle by byl asi vedlejší produkt toho, že bys cachoval dotazy SELECT *
> from tabulka WHERE něco. Pokud by to bylo pro tento typ dotazů
> implementováno cachování ať již rozparsovaných dotazů nebo třeba i výsledků
> (samozřejmě by musela být implementována nějaká invalidace záznamů v cache
> po INSERT, UPDATE, SELECT FOR UPDATE apod.), byla by podpora

 Cachovan bude (pokud to protlacim prez Toma Lane..) kompletni UNION. Co se
tyka invalidace tak to jsi uhodil hrebik na hlavicku --- to totiz neni az
zase takova legrace, bohuzel se to tyka i cache naparsovanych dotazu nebo
VIEW, PL/SQL, SPI apod. kde predelani operatoru znamena nefunkcnost ulozeneho 
dotazu kde je pouzit. Napr. pro PG zatim nikdo rozumne reseni nepredvedl..

> automatická. Když už jsme u toho - má nějaký Open Source DB server podporu
> materialized VIEVs?

Ono je co se tyka VIEW z ceho vybirat?

					Karel



Další informace o konferenci Databases