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