postgresql o mysql?

[ric.cpp]

ciao a tutti,

come da oggetto, vorrei sapere se postgresql offre qualche vantaggio in più rispetto a mysql. Se non sbaglio qualcosa dovrebbe offrire per quanto riguarda le transazioni, ma non so esattamente di cosa si tratta..

[krumiro]

PostGres offre di più per la licenza

[ric.cpp]

cioè? che tipo di licenza ha?

[krumiro]

PostGres è utilizzabile anche per applicazioni commerciali (anche embedded) in modo totalmente gratuito.

MySQL è gratuito solo per applicazioni non-commerciali.

[daniele_dll]

quello è l'ultimo dei problemi ... postgres ti da le UDF, le Stored Procedures, le subqueries, i triggers le referenze gestite a dovere ... le transizioni gestite a dovere ...

tutte queste cose le hai con mysql >= 5.0

con il 4.1 ... hai comunque le udf, le transizioni, le referenze e le udf ben gestite ... quindi se non ti servono cose ancora + avanzate ... puoi benissimo lavorare con mysql 4.1

anche xche postgresql è + difficile da trovare rispetto a mysql 4.1 ... anche se sono ancora molto pochi quelli che montano il 4.1 :\

[geko]

Daniele_dll ha perfettamente ragione. Aggiungo che PostgreSQL è più orientato ad applicazioni mission-critical, proprio grazie alle caratteristiche suddette. MySQL dal canto suo dà la possibilità di utilizzare degli engine diversi per le tabelle tra cui le ottime MyISAM che non supportano molte delle caratteristiche avanzate, ma hanno prestazioni notevolmente superiori, sia su piccole che su grandi moli di dati.

[ric.cpp]

una migrazione da mysql a PostgreSQL implica la totale riscrittura del database o esiste la possibilità di una migrazione indolore?

[daniele_dll]

[supersaibal]Originariamente inviato da ric.cpp
una migrazione da mysql a PostgreSQL implica la totale riscrittura del database o esiste la possibilità di una migrazione indolore? [/supersaibal]

la migrazione è SEMI indolore se il codice è scritto BENE e usa sintassi SQL standard ... ovviamente anche il codice deve essere scritto a modo, meglio se utilizzi un db abstraction layer ... onde evitare di modificare tutto il codice per farlo andare con postgresql (dato che cambiano le funzioni)

[mcagnoli]

Salve a tutti,
mi permetto di dissentire dai giudizi espressi sui due database. Per motivi di lavoro utilizzo entrambi in ambienti di produzione e le conclusioni a cui sono giunto sono differenti dalle vostre.
E' senza dubbio vero che il postgresql ha molte funzionalità in più rispetto al mysql, ma nessuna di queste rappresenta una feauture indispensabile per un database. Non va dimenticato, infatti, che sebbene le stored procedure ed i trigger siano delle funzionalità che ormai sono entrati a far parte dell'utilizzo comune nei database professionali, queste non sono altro che delle interfacce programmative. Il compito principale di un db non è quello di rappresentare una piattaforma di sviluppo, bensì un contenitore di dati. I principali parametri di confronto tra due db dovrebbero essere l'efficienza della gestione dei dati, la sicurezza, le performance, la robustezza, la documentazione. Da tutti questi punti di vista, la mia esperienza è che il mysql sia molto puù "prodotto" rispetto al postgresql.
Attualmente gestisco con ottimi risultati un db mysql con 40 Gb di dati e 400 milioni di record; con il postgresql non sono semplicemente riuscito ad implementare una cosa del genere.
Da non sottovalutare il meccanismo di replicazione del mysql che consente di ottenere sistemi fault tollerant e il raffinato tuning hardware.
Esistono inoltre molte aziende, anche italiane, che offrono servizi di assistenza professionali.
Circa il discorso della licenza, poi, considerate che i soldi sono da pagare alla mysql solo in caso di vendita (e quindi guadagno) del prodotto. Non mi pare poi una grande limitazione.

Queste le mie impressioni, giusto per dare uno spunto in più di riflessione.

Saluti

[daniele_dll]

[supersaibal]Originariamente inviato da mcagnoli
Salve a tutti,
mi permetto di dissentire dai giudizi espressi sui due database. Per motivi di lavoro utilizzo entrambi in ambienti di produzione e le conclusioni a cui sono giunto sono differenti dalle vostre.
E' senza dubbio vero che il postgresql ha molte funzionalità in più rispetto al mysql, ma nessuna di queste rappresenta una feauture indispensabile per un database. Non va dimenticato, infatti, che sebbene le stored procedure ed i trigger siano delle funzionalità che ormai sono entrati a far parte dell'utilizzo comune nei database professionali, queste non sono altro che delle interfacce programmative. Il compito principale di un db non è quello di rappresentare una piattaforma di sviluppo, bensì un contenitore di dati. I principali parametri di confronto tra due db dovrebbero essere l'efficienza della gestione dei dati, la sicurezza, le performance, la robustezza, la documentazione. Da tutti questi punti di vista, la mia esperienza è che il mysql sia molto puù "prodotto" rispetto al postgresql.
Attualmente gestisco con ottimi risultati un db mysql con 40 Gb di dati e 400 milioni di record; con il postgresql non sono semplicemente riuscito ad implementare una cosa del genere.
Da non sottovalutare il meccanismo di replicazione del mysql che consente di ottenere sistemi fault tollerant e il raffinato tuning hardware.
Esistono inoltre molte aziende, anche italiane, che offrono servizi di assistenza professionali.
Circa il discorso della licenza, poi, considerate che i soldi sono da pagare alla mysql solo in caso di vendita (e quindi guadagno) del prodotto. Non mi pare poi una grande limitazione.

Queste le mie impressioni, giusto per dare uno spunto in più di riflessione.

Saluti [/supersaibal]

concordo perfettamente con te ... ma in certe situazione mysql è "scomodo" ... non ho dubbi che possa tenere anche miliardi di dati ... ma il numero in se conta poco ... c'è da vedere cosa ci sta in quei miliardi di dati e come vengono gestiti

se fai una semplice query ... ah beh ... credo che anche alcess +/- vada bene ... ma se vai a fare cose + complesse c'è da rifletterci un attimino...

per i software ben strutturati con database normalizzati capita con facilità la necessità di dover usare subqueries (cosa che la ver 4.0 e precedenti non supportano) e quindi si è costretti a costruire tutto un sistema interno per joinare i dati di 2 query e poi visualizzarli ... sistema decisamente scomodo

è normale che per il sito personale ... o anche di una ditta ... ma che ci stanno su news, offerte o altro ancora ... non accenno nemmeno a postgres ... ma se mi ritrovo in una situazione dove c'ho svariate tabelle xche ci sono strutture intricate tra di loro (9 listini, ogni listino può essere agganciato ad un cliente, le offerte possono essere per cliente o per listino ma sempre per prodotto, le offerte variano i propri periodi, le condizioni commerciali cambiano da periodo a periodo ... ecc ecc ecc) è "scomodo" non poter avere almeno le subqueries ... certo ... non capita ogni giorno ... ma quando capita sono rogne

quindi, ripeto quello che ho detto all'inizio ... mysql è ottimo nell'80% dei casi ... ma in quel 20% c'è da scegliere se usare mysql 4.1 (ma si necessità al 90% un server proprio), usare postgresql ma si deve cercare un hoster che lo supporti oppure tenere mysql 4.0 e fare il lavoro che deve fare il db al linguaggio di scripting

inoltre questa terza opzione comporta un carico MOLTO maggiore al server ... in ambienti distribuiti ritrovarsi con 2 macchine distinte ... e poi leggere e scrivere ... e basta da quella del database ... penalizza notevolmente la performance ... xche alla macchina database si possono far svolgere funzioni e procedure che alleggerirebberò notevolmente il carico del server principale ... riducendo anche i costi

ad esempio se vbulletin usasse le subqueries e le stored procedures, sicuramente html.it, per il forum, avrebbe avuto bisogno di meno macchine per il web e di potenziare quella del db ... ma bastava potenziare di poco quella del db ... e risparmiare una macchina web ... e se proprio era necessario con i costi della web si potenziava la db ... ma comunque si avrebbe risparmiato xche il lavoro principale lo fala db e quindi le altre due macchine sarebberò + leggere e tutto sarebbe meglio distribuito

i tempi di esecuzione molto spessi non sono alti per l'esecuzione delle query ... che ci stanno millesimi di secondo molto spesso ... ma nel codice, che scritto male, provoca cali performace ... e se scritto bene ... comunque il 70% dei tempi di esecuzione sono suoi ... quando si può passare dai 70 ... ai 50 o 60 ... già c'è un risparmio ... anche nei costi perché non si "butta" tempo di esecuzione inutilmente