Mysql a "transakce"

Zakkr zakkr na zf.jcu.cz
Středa Srpen 18 17:00:20 CEST 1999



On Wed, 18 Aug 1999, Jan Kasprzak wrote:

> 	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?
 
 PostgreSQL pochopitelne velke objekty umi. Obsahuje API pro
'large object' (lo) a pouzivani je pak velmi podobne jako u souboru 
(open / close / seek). Ale je pravda, ze to pak neni primo v tabulce
tam je jen 'oid'. Je to ale logicke proc do tabulky davat takove velke
veci - a potrebuje-li nekdo prohledavat takovato data tak muze pouzit 
nejakeho naindexovani a v tabulce mit ten index.

(I kdyz: existuje neco co projde soubor a udela z obsahu index 
 	(neco jako htdig dela s webem, ale do SQL)? ) 

 Jinak PgSQL zatim ma buffer na dotaz 8*1024. Jinak viz. vyse (lo).

> 	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.

 Jasne, kazda legrace neco stoji. No reseni je (asi) to co uz tu nekdo napsal:
mit cast databaze "nanecisto" a nejak chytre to prevadet do "ciste" casti
(a prevadet urcite radeji triggrem na serveru nez server->client->server).
Ale i tak si myslim, ze mocnejsi nastoje budes mit v rukou u PostgreSQLu.
 
						Zakkr

PS. drza zvedavost: o co jde? - treba nekoho jeste neco napadne... 

								
 



Další informace o konferenci Databases