Mysql a "transakce"

Jan Kasprzak kas na informatics.muni.cz
Středa Srpen 18 17:22:38 CEST 1999


Zakkr wrote:
:  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.
: 
	Jo, ale velke lo prave neni to, co chci. Zejmena LO nejde rozumne
plnit a cist po siti, pokud si pamatuju. Ja bych proste chtel, aby se
to chovalo jako longblob v MySQL - to jest jako kazdy jiny radek
v tabulce.

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

	Jeste existuje glimpse, ale to neni do SQL. A pak (bonz, bonz :-)
ma adelton nejake indexovatko pro MySQL jako perlovy modul, ale
jeste to nema dopracovane (adeltone: release early, release often!).

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

	No, to je prave ono. Lo nefunguji po siti.

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

	No, ja si myslim, ze tou pomocnou tabulkou s AUTO_INCREMENT bych
to vyresil lepe. Ono nejde o skutecny CPU time toho serveru, jde o to,
aby www klienti (z jineho stroje) pracovali s databazi co nejrychleji.
To znamena, ze kdyz chce neco WWW klient, ma se to udelat rychle a bez
triggeru, a pak samostatnym demonem to jednou za cas uvest do konzistentniho
stavu.

: Ale i tak si myslim, ze mocnejsi nastoje budes mit v rukou u PostgreSQLu.

	Skoro na vsechno - az na longblob.

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

	Web-based e-mail. Ale ono uz je to v provozu, jak jsem psal, cili
zmena databazoveho stroje neprichazi v uvahu.

-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