firebird vs. postgres

Karel Zak zakkr na zf.jcu.cz
Středa Květen 29 10:31:45 CEST 2002


On Tue, May 28, 2002 at 10:49:37PM +0200, Ondrej Koala Vacha wrote:
> Trochu mi uchazi, v cem je rozdil, jestli se o integritu staram sam, nebo 
> sam prostrednictvim stored procedures. Uznavam, ze pomoci SP je to 
> elegantnejsi, ale nakonec je to jedno, nebo ne?
> Pokud je to mysleno tak, ze klient muze cokoli, a teprve SP to davaji do 
> poradku, pak je take reseni vyhodit klienta. 

 Asi by to chtelo vice osvety a mene emoci :-), tedy:

 Integrita by mela byt zanesena uz v navrhu dane DB. Pokud nezadate
 neco specialniho (coz vetsinou ne) tak nemusite psat ani byte nejake
 "stored procedure". Proste jen v definici tabulky uvedete FOREIGN KEY
 (apod.) a server se sam stara o korektnost vazby danych tabulek.

 Pokud toto budete chtit, delat na strane klienta tak to znamena
 udelat nejake misto (rikejme mu uzke hrdlo:-) ktere bude kotrolovat
 co delaji vsichni klienti a nebo to budete muset resit zamkama na
 tabulkach a overovat ta data v DB (coz je lepsi).

 Poradna DB, ale nepouziva zamek na celou tabulku, ale jen na
 relevantni radky. Coz dost vyrazne pomaha vykonu. Obavam, se ze neco
 takoveho _nikdy_ na strane klienta neudelate. Pridale-li do toho
 jeste transakce tak to znamena udrzovat ruzne verze techto radek
 pro aktualne bezici transakce. Impelementace neceho takoveho je
 zalezitost nekolika let :-)

> "Ing. Miloslav Ponkrác" wrote:
> > InnoDB provides ACID compliancy.
> > 
> > U MySQL si můžete zvolit typ databázových tabulek. Typ InnoDB je IMHO
> > nejlepším pro podporu transakcí, a ACID zvládá.
> 
> 	A nejsou nahodou tyto InnoDB tabulky pouze rozhranni nad BerkeleyDB - v
> podstate takove jednoduse slozitejsi hashovaci tables... - v databazich
> bezneho typu moc nepouzitelne... navic pokud se do te dokumentace

 Tady bych se asi MySQL zastal. Pokud mne pamet nemate tak InnoDB je
 postaveno na SleepyCat (http://www.sleepycat.com/) coz je vec ktera
 ma z Berkeley Univ. hodne spolecne, ale urcite to nejsou ty hash
 tabulky co je zname. Je to vrstva umoznujici transakcni praci s
 tabulkama. Lze rict, ze je to knihovna kterou muzete dat ke sve
 aplikaci a naucit ji tak transakce a jine advanced DB features :-)

> podivate poradne, zjistite, ze InnoDB nejsou plnohodnotne tabulky z
> pohledu databazovy objekt a nelze tedy je brat vazne... - je to jen
> takova zaslepka neceho, co puvodni autori MySQL povazovali za zbytecnost
> a cim dal vice lidem to chybi, bohuzel zpravidla az ve chvili, kdy

 O tom uz se na ruznych mistech debatovalo. Ten smer/styl vyvoje MySQL 
 v poslednich cca 2 letech je celkem zajimavy.

On Wed, May 29, 2002 at 09:05:47AM +0200, Ondrej Koala Vacha wrote:
> 
> Tady bych se rad dozvedel vice - zkusil jsem jednou InnoDB, a co se 
> rychlosti tyce dopadly stejne jako myisam. Proc by mely byt nepouzitelne?
> 

 Aniz bych chtel rikat neco o kvalitach nejakeho SQL stroje, tak
 zrovna rychlost bych nepovazoval za meritko.

 Ostatne kdyz jsme u te MySQL. Co je to rychle? 
 
 Je to "time mysql -c prikaz" a nebo je to treba 100 soucasne pracujicich
 klientu z nichz treba 20% provadi UPDATE/INSERT/DELETE nad stejnyma
 tabulkama? 
 
        Karel
-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz


Další informace o konferenci Linux