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