InnoDB u mysql (was: firebird vs. postgres)

Ing. Pavel PaJaSoft Janousek janousek na fonet.cz
Pátek Květen 31 09:10:07 CEST 2002


Karel Zak wrote:
>  Ja si umim nasazeni MySQL celkem predstavit. Napriklad nejaky
>  redakcni Web system kde 99% dotazu je cteni apod. Problem je, ze

	Pak to ovsem je spise Adresarova sluzba nez relacni databaze => LDAP si
v tomto pripade dovedu predstavit jako velmi dobry background. Pripadne
BerkeleyDB a nebo stare dobre DBF a nejaky engine nad nim, proc do toho
rva relacni datove modelovani a 'zivost' systemu?

> On Thu, May 30, 2002 at 09:45:19AM +0200, Ing. Pavel PaJaSoft Janousek wrote:
> >       Nejak jsem explicitne nevycetl, zda-li umi jednu InnoDB table pres vice
> > souboru => zrejme ne, tedy jedna tabulka muze mit velikost maximalne co
> > podporuje FS... a jak na jinem miste vime (precteme si) je to zpravidla
> > 2GB, nic moc...:-(
> 
>  Nedavno se ozval do PostgreSQL konference clovek s 20GB databazi
>  (nebo tak nejak) a ze pry ma tabulku jejiz index ma 3GB.

	Toto jsem nepochopil - clovek co pouziva MySQL na Linuxu nebo clovek co
pouziva PostgreSQL nekde?

> > Starting from version 3.23.50 you can also associate the ON DELETE
> > CASCADE or ON DELETE SET NULL clause with the foreign key constraint.
> 
>  S plnou implementaci FK maji problem i komercni SQL. Pokud mne pamet
>  nemate tak DB2 nema ON UPDATE CASCADE, ale jen RESTRICT (pokud to
>  neni zalezitost verze). Ono to implemntovat neni snadne.

	Na slozitosti se shodneme, ale co kdyz nemam zajem provest ON DELETE
CASCASE, protoze ja pitomec jsem zapomnel, ze je to svazano s jinymi
vecmi - a uprimne receno, mam-li objekt A, na ktery je referencovan
objekt X, pak objekt A o tomto z hlediska programatora v podstate nic
nevi... Takze ta volba ON DELETE CASCADE je fine, ON DELETE SET NULL
take, ale to mi bud a) porusi referencni integritu (proc tedy pak FK
pouzivat?) a nebo odmitne, protoze prave ten objekt X neobsahuje null...
- toto jsou veci, ktere z hlediska programatora mne nemaji vubec
zajimat.

BTW Jsem si vedom toho, ze muj pohled je trochu 'zkresleny' - divam se
na prodkty primarne jako vyvojar, ne produkcni 'oprasovac', z hlediska
produkce nejsou nektere veci tak 'ostre', z hlediska vyvoje je to vsak
nebe a dudy.

> > When doing foreign key checks InnoDB sets shared row level locks on
> > child or parent records it has to look at. InnoDB checks foreign key
> > constraints immediately: the check is not deferred to transaction
> > commit.
> >
>  Opet vec v plne implemntaci FK definovatelna:
> 
> DEFERRABLE or NOT DEFERRABLE

	Ja vim, prave proto o tom mluvim... a docela by mne zajimalo, jak
obejit toto striktni omezeni v okamziku, kdyz modifikaci databaze nejsem
schopen popsat jednim DML prikazem? Nebo jak vubec modifikaci databaze
provest?

> > - tak a tady si troufam rici, ze lzou! Srovnejte language-binding,
> > srovnejte v cem lze psat stored-procedury/triggery, kde mame
> > EmbeddedSQL atd...?
> 
>  IMHO az jednou bude Java a funkce poradne vracejici radky tak v tomto
> necha PG ostatni dost za sebou :-)

	Ja si myslim, ze prave diky vlivu Oracle a jeho Pro*X [X = Fotran,
Basic, Pascal, C/C++, Java] je ESQL mohutny nastroj, ktery v komercnich
systemech ma povedomi (i MS ho nakonec doplnil, ostatni to maji davno,
byt treba ne pro vsechny jazyky - a IMHO je to daleko lepsi (vcetne
normy) nez C-library apod.), v Open source jsem siroko daleko jediny
exot, ktery ho pouziva a chape jeho vyhody (nevyhody jsou tak
zanedbatelne, ze mne v tuto chvili vazne nenapada zadne vyznamne
omezeni) - a pokud bych jo mel problem, mame tu obecna rozhranni ala
ODBC ci JDBC (zde je to pro zmenu vazano jazykem).

> > - tvrzeni, ze context switching je rychlejsi je otazka implementace
> > threadu, ne otazka vykonu databaze...
> 
>  Thready zvetsuji slozitost i kdyz je pravda (IMHO), ze pri
> poradnem pouziti mohou byt efektivnejsi. Osobne nejsem proti nim.

	Obecne nejsem proti nicemu, co v realnem nasazeni odpovida vykonu, ale
implementovat neco jen quli tomu, abychom byli-in nebo byl sef vyvoje na
masazi a to 'NECO SUPROVEHO' jeste v nasem produktu chybi je cesta
pomerne podivna...

> > All MySQL table types (except InnoDB) are implemented as files (one
> > table per file), which makes it really easy to back up, move, delete,
> > and even symlink databases and tables, even when the server is down.
> >
> > - ehm, co treba file-size file-system omezeni? Tyto vyhody osobne v
> > dnesni dobe povazuji za spise nevyhody...
> 
>  PostgreSQL take pouziva soubory. IMHo to nema nic do cineni s
>  omezenim FS, proste se tech souboru udela vice.

	No vybavuji si urcitou debatu o RAW zarizenich...;-)

> > Much slower INSERT, DELETE, and UPDATE.
> 
>  Az bude muset MySQL behem jednoho dotazu udelat to co PostgreSQL tak
>  to pujde srovnavat. Takto je to jabka vs. hrusky.

	Souhlasim. Pokud vsak nekdo takto blbe argumentuje, vim s jakou vahou
mam brat jeho argumenty. Ja nesrovnavam MySQL s jinymi produkty, ja
kritizuji MySQL dokumentaci za lzi, pripadne polopravdy a neuplna
tvrzeni - a to se netyka jen PostgreSQL.

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------


Další informace o konferenci Test