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