linux user group brescia

On Mon, Mar 18, 2002 at 10:19:54PM +0100, Ella Chan wrote:
> 
> Salve, ho creato un frontend con delphi utilizzando i componenti ZeosLib per
> interfacciarmi con PostgreSQL 7.1.3 e non ho trovato problemi alcuna. Voglio
> segnalare però che ZeosLib non funziona con la nuova versione pg 7.2, ho
> dovuto ritornare alla versione precedente. Ho anche mandato un email al
vero. funziona solo fino alla versione di postgres 7.1.3 compresa. oddio,
il problema dovrebbe sorgere semplicemente dalla modifica, con la release
7.2, della table pg_index... detto questo, non avendo mai usato, ne`
conoscendo, zeoslib, non so dirti se il tutto si riduce ad un one-line-fix
o a qualcosa di + complesso...
innegabilmente, pero`, il salto di qualita` dalla 7.1 alla 7.2 e` notevole
(e sara` bene aggiornarsi subito alla prossima release 7.2.1, branchata
oggi, che corregge un bug verramente antipatico, per quanto raro).

> master di ZeosLIb di segnalazione del problema ma non ho avuto nessuna
> risposta.
hai fatto bene, ad ogni modo la cosa e` nota da tempo (in pgsql-interfaces
si e` discusso della cosa il 21 febbraio).

> Ora voglio fare un pò di pratica anche con MySQL.
> Qualcuno sà indicarmi i pregi e/o difetti di MySQL e PostgreSQL o quale
> delle due è meglio utizzare in ambiente professionale.
la discussione e` lunga, e non puo` che generare una guerra di religione...
brevemente, mysql e` stato sviluppato con la prerogativa della velocita`,
cosa che ha comportato:
a) sacrificio di funzionalita` intrinseche ai db relazionali (foreign
keys, transazionalita`[1], ecc)[2]
b) uno sviluppo orientato prevalentemente alla realizzazione di prodotti
web (soprattutto contando sul fatto che all'epoca postgres era poco piu`
che un buon progetto universitario, che mancava di tutta una serie di
caratteristiche necessarie)

postgres, per quanto possa essere ancora migliorato, e` un db relazionale a
tutti gli effetti, con tutti i vantaggi che questo comporta (ovvero, si possono
delegare al db tutta una serie di preoccupazioni, che all'atto pratico
si traducono in meno righe di codice scritto, e meno possibilita` di
sbagliare)... non solo, le specifiche sql sono totalmente rispettate,
permettendo di scrivere codice portabile e di sbizzarrirsi nella stesura
delle query (al momento uno dei problemi e` che il query planner va, a
seconda dei casi, aiutato in vari modi). lo scotto da pagare e` la conoscenza,
per quanto non troppo approfondita, necessaria per poter sfruttare appieno
postgres.

personalmente nel dover gestire dati di una certa complessita` preferisco
appoggiarmi a pg, mentre per gestire anche grossi volumi di dati grezzi
preferisco sfruttare barbatrucchi sui flat file, possibilmente in ascii...
ad esempio, un db engine, non relazionale ma molto efficiente, e` il
berkeley db, con il quale gestisco un db di qualche decina di mbyte.

in ogni caso, l'argomento e` molto piu` complesso di quanto sembri, e il
grado di incompetenza che si respira nell'aria e` elevato (sostenere ad
esempio che il crash recovery di mysql sia fico basandosi semplicemente su
esperienza personale "lo uso da n mesi e non ho perso nulla", non e` utile
nella valutazione di un db, ed e` sciocco).

ciao,
andrea

--------


[1] la soluzione adottata in mysql 4.0 per le transazioni mi preoccupa non
poco
[2] personalmente ritengo mysql un db generico, sicuramente non
relazionale