[Tech] Interbase

[Marco Ermini]

Franco Bagnoli wrote:
> 
> On Fri, 17 Nov 2000, Claudio Cicali wrote:
> 
> > In data 01:44 AM 11/17/00 +0100, Marco Ermini ha scritto:
> >
> > Scusate se sono un po' OT su questo thread, ma:
> > fino a poco tempo fa ero un fan di MySQL (per siti medio piccoli,
> > naturalmente), di cui elogiavo la velocita' e minor complessita'
> > rispetto a Postgrs.
> > Poi ho letto questa prova comparativa :
> > http://www.phpbuilder.com/columns/tim20000705.php3
> > e mi sono divuto ricredere.
> >
> > Postgres 7.1 (ancora in fase di pre-beta) e' assolutamente una BESTIA,
> > altro che "quasi valido" :)
> 
> scusa, sono interessato perche' dovrei far partire un progetto proprio in
> questi giorni e devo scegliere tra mysql e postgres. Mi sembra che dalla
> review citata emerga che postgres "tiene meglio" un grande volume di
> traffico e non si pianta da solo, mentre mysql garantisce di non
> incasinare il database in caso di crash (e questo mi sembra
> importantissimo). Inoltre postgres implementa il
> concetto di transaction, e mysql no. 

Non e' completamente corretto, perche' se compilato con il supporto per
Berkeley DB di SleepyCat, anche MySQL puo' gestire le transazioni (a
livello di tabella).

Il concetto e' che se ti servono le transazioni, devi usare PostgreSQL.
Altrimenti dovresti usare MySQL. Tieni conto che molte procedure scritte
pensando all'uso di transazioni possono essere riscritte utilizzando le
lock di MySQL, le quali pero' agiscono sempre a livello di tabella: e'
questo il punto su cui si incentra l'articolo citato da Claudio: se stai
inserendo mentre una tabella e' lockata, per esempio, in aggiornamento
da un altro thread, con MySQL vieni "bloccato" finche' il primo processo
non ha rilasciato la tabella (dato che il lock e' a livello di tabella)
anche se le righe interessate dai due thread sono diverse; con
PostgreSQL *potresti* avere la possibilita' di effettuare
l'aggiornamento se le righe interessate sono diverse - questo perche' il
lock e' a livello di riga.

Questa e' solo una delle tante, vecchissime discussioni sui DBMS: il
lock a riga rende la gestione complessiva di select/insert/update piu'
lenta (e quindi il DB piu' lento), ma se implementiamo un software con
molti utenti, questo potrebbe essere reso nel complesso piu' veloce con
questo tipo di gestione, perche' con molti accessi concorrenti ad una
tabella il lock a livello di riga "libera" prima i thread di
aggiornamento (che quindi anche se sono piu' lenti possono essere
eseguiti contemporaneamente). E' una discussione piu' vecchia di mio
nonno che esiste per lo meno da 20 anni, da quando esistono i DBMS. Per
questo l'articolo su PHP Builder e' parziale: prima cosa si vede che
l'autore non conosce tutte queste vecchie diatribe ;-) e poi non esiste
una risposta precisa, o meglio la risposta e': DIPENDE... ;-) dipende da
cosa vuoi fare e da come lo fai. Il DB dovrebbe essere scelto dopo che
tutta l'applicazione e' gia' stata progettata... certo se PostgreSQL,
pur implementando il lock a riga, riesce ad essere veloce quanto MySQL
(o anche solo ad avvicinarsi, perche' ricordiamoci che PostgreSQL prima
di 7.1 era *decine* di volte piu' lento di MySQL!!!) questo cambia molto
le carte in tavola...


> Pero' postgres ha un limite nella
> dimensione della row e mysql no, e gia' questo semplifica la vita un bel
> po' (almeno per quello che devo fare). Inoltre la review si chiude con:
> 
> "Finally, for the hardest-core developers, Postgres could be pretty
> slick. Foreign keys, views, subselects, and transactions can all
> be pretty cool -- if you need them and you will
> make any use of them. If you don't need them or won't use them, then
> you're probably better off with MySQL and its superior
> performance."
> 
> che mi sembra piuttosto chiaro. Per la tua esperienza, quali sono i
> vantaggi piu' evidenti di postgres?

Il problema di PostgreSQL e' che come software e' secondo me una "via di
mezzo": implementa alcune delle features dei grossi RDBMS ma non le
implementa tutte e non bene (ovvero, se ti serve un "vero" e "sicuro"
RDBMS, con replicazione dei dati ecc. senz'altro Sybase ed Oracle sono
*molto* migliori). MySQL non fa altro che quello che dice di fare, lo fa
e lo fa molto bene. Dal mio punto di vista PostgreSQL e' utile soltanto
se non puoi permetterti (o per motivi "filosofici" non vuoi usare) un
RDBMS commerciale tra quelli su citatil, che altrimenti sono sempre
meglio di PostgreSQL.
Probabilmente, e' la dimensione/complessita' della tua applicazione che
ti dovrebbe guidare verso la scelta di un DB... Ripeto e' il mio punto
di vista.




ciao ciao ciao

-- 
Marco Ermini
http://www.markoer.org
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.      -- Jeremy S. Anderson