Mysql a "transakce"

Jan Kasprzak kas na informatics.muni.cz
Středa Srpen 18 11:29:51 CEST 1999


Zakkr wrote:
: > 	Existuje v MySQL nejake jednoznacne cislo klienta?
: > Existuje jine reseni?
: 
:  Tady by asi bylo dobre zamyslet se nad tim je-li MySQL to prave...
: Ono simulovat transakce, kdyz jiz existuji v (napr.) PostgreSQLu. 
: Myslim, ze by ti to hodne pomohlo a je tam i daleko vice dalsich veci
: (napr. triggery - proc si zapsani neceho do tabulky nespojit s nejakou
: funkci - napsanou napr. v  'C' (viz. ten cteci proces) ... atd.).
: A taky se tam lepe programuje.
: 
:  Asi obecne pokud nekdo chce viceuzivatelskou databazi a neco slozitejsiho 
: tak je to presne ta chvile kdy je dobre rychle zapomenout na MySQL.

	Samozrejme ze jsem velmi dlouho vahal, jaky databazovy stroj
poridit. Dokonce jsem ten system zacinal psat v MySQL i v PostgreSQL,
abych videl, jak se s tim pracuje. Bohuzel ted uz neni vicemene cesta
zpatky, system uz bezi a tohle jsem potreboval jen pro upravu urcite casti
(ukazalo se, ze kdyz zapisuju >10000 radku se zamcenou tabulkou, vadi
to ostatnim klientum te databaze).

	Hlavnim duvodem, proc MySQL, byly velke objekty. Treba se situace
zmenila? Muze mit postgres primo v tabulkach objekty velke okolo
megabajtu, delat nad nimi LIKE a podobne? A jak je na tom s maximalni
velikosti SQL dotazu a odpovedi?

	Ohledne triggeru - ja jsem nakonec vzdal i to, aby klienti
sami udrzovali nejakou konzistenci mezi tabulkami. Zjistil jsem, ze 
pokud potrebuju rychlou odezvu (pro WWW klienty), musi toho CGI skript
delat na databazi co nejmene. Takze jsem zavedl nekonzistence a mam
samostatny proces, ktery parkrat za den vymaze z databaze radky, na ktere
nejsou odjinud odkazy. S vyvolavanim triggeru by to bylo jeste horsi.

-Yenya

-- 
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz>       http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\             Czech Linux Homepage:  http://www.linux.cz/              ///
| The case with NT is the most spectacular.  Seems, they have at least two |
| independant teams.  One introduces bugs, another invents workarounds.    |
| Silly bugs are followed by ugly workarounds. 8)       --Alexey Kuznetsov |


Další informace o konferenci Databases