# MySQL vs postgreSQL

## GuN_jAcK

 *k.gothmog wrote:*   

> permettimi un consiglio: se non hai vincoli esterni, e soprattutto se si tratta di un progetto serio, e non di un giocattolo, lascia perdere mySQL, e preferisci PostgreSQL... sempre che tu possa

 

[OT] scusate che entro brevemente in OT.. ma perchè dici che è meglio evitare MySQL?  [/OT]

----------

## .:chrome:.

 *GuN_jAcK wrote:*   

> [OT] scusate che entro brevemente in OT.. ma perchè dici che è meglio evitare MySQL?  [/OT]

 

siamo maledettamente OT, ma almeno ti rispondo.

perché mySQL è nato per essere un giocattolo, non un db serio. con il tempo è evoluto, ma un giocattolo era ed un giocattolo è rimasto.

con la versione 5.0, che però non è ancora stabile, comincia a sembrare un db serio e fatto come si deve. peccato che tutto quello che fa mySQL 5.0 (e anche di più) lo facesse già postgreSQL 7.0.

ha di bello che è facile da usare. per uno che vuole fare la sua paginetta web che pesca dati da un db, sarebbe stupido usare qualcos'altro, ma se le applicazioni diventano seriem allora il discorso cambia. ho bisogno di qualcosa di solido, qualcosa che mi permetta funzioni di un certo tipo, non solo di fare query stupide. ho bisogno di flessibilità e di un dbms che non aumenti il carico sul sistema con il crescere delle dimensioni della base di dati.

potrei andare avanti, ma non voglio esagerare, visto che siamo OT.

per concludere rimando solo a questo documento, di flameEyes: http://dev.gentoo.org/~flameeyes/articoli/mysqlsevil.pdf

----------

## fikiz

mi permetto di dissentire. non conosco PostgreSQL, ma MySQL lo conosco piuttosto bene e di certo non e' un giocattolo. Per scelta progettuale degli sviluppatori, offre poche caratteristiche a favore di velocita' e stabilita'. Obiettivi che hanno assolutamente raggiunto. certo, non e' Oracle, ma dubito che qualunque database non commerciale attualmente possa essere confrontato con Oracle   :Wink: 

La versione 5 e' stabile da circa un paio di mesi. Io la uso in produzione da qualche giorno per un gestionale di medie dimensioni.

Stando a quello che chiedi, che se ho capito bene vuoi indicizzare dei documenti tramite database, e' MySQL e' perfettamente in grado svolgere questo compito. In piu', come dice gothmog, e' piuttosto semplice da installare, configurare e manutenere.

ciao!

----------

## .:chrome:.

"giocattolo" non era detto in senso assoluto, ma relativo, e bisogna ammettere che lo è, in contronto a Oracle.

per la mia tesi ho fatto un confronto tra mySQL e postgreSQL, ed è inutile che scriva cosa è risultato migliore. credo sia scontato.

ho anche preso molti riferimenti da un documento del CERN (se non ricordo male) che confrontava mySQL, postgreSQL, e Oracle. lì mySQL è stasto letteralmente massacrato. la cosa interessante è che la stessa sorte è toccata a Oracle, in quanto postgres offriva le stesse features, nulla di meno, ed a volte qualcosa di più

----------

## gutter

Ho fatto uno split di questo thread dal momento che si stava andando OT.

Spero che la discussione sia costruttiva   :Wink: 

----------

## .:chrome:.

 *gutter wrote:*   

> Ho fatto uno split di questo thread dal momento che si stava andando OT.

 

hai fatto bene... ormai eravamo finiti completamente fuoir strada. chiedo scusa aper aver contribuito all'OT.

----------

## fedeliallalinea

A me pare anche che fino a qualche tempo fa mysql non era transizionale, ovvero non era del tutto atomico e le transizioni potevano essere eseguite a meta' cosa che in un db non dovrebbe esistere (nel senso o un'operazione va a buon fine o non viene eseguita)

----------

## .:chrome:.

 *fedeliallalinea wrote:*   

> A me pare anche che fino a qualche tempo fa mysql non era transizionale, ovvero non era del tutto atomico e le transizioni potevano essere eseguite a meta' cosa che in un db non dovrebbe esistere (nel senso o un'operazione va a buon fine o non viene eseguita)

 

questo problema è stato risolto. adesso è transazionale.

non ricordo se la modifica sia stata fatta con la versione 4 o 5

però ancora una volta... queste sono caratteristiche che postgres ha da sempre  :Wink: 

----------

## fedeliallalinea

 *k.gothmog wrote:*   

> però ancora una volta... queste sono caratteristiche che postgres ha da sempre 

 

Infatti e a partita' di tempo di esecuzione delle query oramai sono uguali, c'e' da sfatare l'idea di mysql piu' veloce (cosa che era cosi' in passato ma perche' implementava anche 1/10 delle cose).

----------

## GuN_jAcK

 *k.gothmog wrote:*   

>  *gutter wrote:*   Ho fatto uno split di questo thread dal momento che si stava andando OT. 
> 
> hai fatto bene... ormai eravamo finiti completamente fuoir strada. chiedo scusa aper aver contribuito all'OT.

 

scusate colpa mia ^_^'

e che ero curioso di quella affermazione....

comunque k.gothmog quindi non è solo un fatto di prestazioni ma anche una questione filosofica? che effetivamente dopo aver letto quel documento condivido abbastanza... l'unica pecca che se sviluppo applicazioni web non so a che punto mi può convenire usare PostgreSQL... raramente becchi server con un'altro DB installato oltre a MySQL.. :/

----------

## makoomba

postgresql, nelle nuove versioni, gestisce nativamente (ed in maniera semplice) gli indici fulltext ? 

o si deve ancora utilizzare quell'estensione esterna che era un macello da configurare (tQualcosa) ?

----------

## .:chrome:.

 *GuN_jAcK wrote:*   

> l'unica pecca che se sviluppo applicazioni web non so a che punto mi può convenire usare PostgreSQL... raramente becchi server con un'altro DB installato oltre a MySQL.. :/

 

purtroppo hai ragione. anzi no... i server li trovi, ma postgreSQL è un servizio a pagamento, mentre mySQL spesso te lo danno A GRATIS nel pacchetto. fatto sta comuqnue che postgres si sta diffondendo molto, sia a discapito di mySQL che di Oracle (ma è proprio quest'ultimo che sta avendo la peggio), quindi con il passare del tempo la situazione non sarà poi tanto chiusa.

 *makoomba wrote:*   

> postgresql, nelle nuove versioni, gestisce nativamente (ed in maniera semplice) gli indici fulltext ? 
> 
> o si deve ancora utilizzare quell'estensione esterna che era un macello da configurare (tQualcosa) ?

 

parli di tSearch? è supportata nativamente, ma i mantainer del pacchetto gentoo non la includono. io l'ho usata una sola volta, ma non c'è la riga nell'ebuild per aggiungerla. mi sono fatto un overlay con una riga in più, nulla di trascendentale

----------

## !equilibrium

 *GuN_jAcK wrote:*   

> l'unica pecca che se sviluppo applicazioni web non so a che punto mi puï¿½ convenire usare PostgreSQL... raramente becchi server con un'altro DB installato oltre a MySQL.. :/

 

ti stai perdendo in un bicchiere d'acqua... se stai facendo un'applicazione web, la prima cosa che impari ad usare sono i DB Abstraction Layer, in modo tale che il tuo applicativo funzioni con diverse sorgenti dati (scrivendo SQL standard). Ne esistono parecchi, commerciali e non, e per quasi tutti i linguaggi di programmazione noti. Hai solo da sbizzarrirti nella scelta ed imparare ad usarli.   :Wink: 

----------

## makoomba

tsearch, sì.

cioè, per avere un indicizzazione fulltext con postgresql, si deve fare ancora tutto 'sto macello ??  :Shocked: 

allora non è cambiato nulla.

----------

## Kernel78

Io è da un po' che cerco di avvicinarmi a postgresql ma mi perdo sempre in un bicchiere d'acqua ... i trigger  :Embarassed: 

Sarà che effettivamente postgresql offre molte più possibilità di personalizzazione cone le funzioni ma come approccio mi è parso meno "user-friendly" persino di blender  :Laughing: 

Personalmente mysql non l'ho mai usato, se mi serve qualcosa di semplice vado su sqlite e per adesso le cose più complesse le ho fatte per dei clienti su db proprietari (leggasi: cachè) ma volevo impararmi anche postgresql.

----------

## GuN_jAcK

 *DarkAngel76 wrote:*   

> ti stai perdendo in un bicchiere d'acqua... se stai facendo un'applicazione web, la prima cosa che impari ad usare sono i DB Abstraction Layer, in modo tale che il tuo applicativo funzioni con diverse sorgenti dati (scrivendo SQL standard). Ne esistono parecchi, commerciali e non, e per quasi tutti i linguaggi di programmazione noti. Hai solo da sbizzarrirti nella scelta ed imparare ad usarli.  

 

chiaro, comunque la mia era solo sete di sapere niente di più (per ora).. anche se PHP lo so usicchiare e non mi dispiacerebbe in un futuro approfondirlo integrandolo con qualche DB... per ora ci sono altre priorità  :Very Happy: 

----------

## makoomba

 *DarkAngel76 wrote:*   

> ti stai perdendo in un bicchiere d'acqua... se stai facendo un'applicazione web, la prima cosa che impari ad usare sono i DB Abstraction Layer, in modo tale che il tuo applicativo funzioni con diverse sorgenti dati (scrivendo SQL standard). Ne esistono parecchi, commerciali e non, e per quasi tutti i linguaggi di programmazione noti. Hai solo da sbizzarrirti nella scelta ed imparare ad usarli.  

 

questo è vero fino ad un certo punto.

le classi di astrazione hanno senso finchè si rimane nel generico, ad un livello medio-alto, l'applicazione deve tener conto del db sul quale opera.

non tutti i backends supportano subqueries, integrità referenziale, views, stored procedures e triggers, quindi il codice va adattato, anche utilizzando funzioni e costrutti propri del dbserver a disposizione.

----------

## !equilibrium

 *makoomba wrote:*   

> questo ï¿½ vero fino ad un certo punto.
> 
> le classi di astrazione hanno senso finchï¿½ si rimane nel generico, ad un livello medio-alto, l'applicazione deve tener conto del db sul quale opera. non tutti i backends supportano subqueries, integritï¿½ referenziale, views, stored procedures e triggers, quindi il codice va adattato, anche utilizzando funzioni e costrutti propri del dbserver a disposizione.

 

si vera e corretta come osservazione, ma a quei livelli, si usa ODBC con driver proprietari che permettono di avere un'astrazione totale sui DB e laddove un DB non supporta la funzione desidera, questa viene emulata per permettere la massima astrazione possibile; ovviamente si parla di prodotti commerciali e molto costosi, perchÃ¨ 'open' non ne esistono (giustamente...).

----------

## !equilibrium

 *GuN_jAcK wrote:*   

> chiaro, comunque la mia era solo sete di sapere niente di piï¿½ (per ora).. anche se PHP lo so usicchiare e non mi dispiacerebbe in un futuro approfondirlo integrandolo con qualche DB... per ora ci sono altre prioritï¿½ 

 

bhe per PHP sei fortunato ci sono solo 2 veri DB Abstraction Layer (tutti gli altri sono fuffa):

- ADODB

- PEAR::MDB (meglio il nuovo PEAR::MDB2)

il + usato Ã¨ ADODB perchÃ¨ Ã¨ stato uno dei primi Abastraction Layer 'completi e funzionanti', PEAR::MDB Ã¨ arrivato dopo, ma non per questo non Ã¨ da prendere in considerazione, ha molte features che ADODB non ha. Io preferisco PEAR::MDB2

----------

## makoomba

bah, gli HAL per php non mi hanno mai convinto, principalmente per i motivi già citati.

in secondo luogo, ma non meno importante, ciucciano troppe risorse e spesso senza una reale necessità.

specialmente PEAR.... di astrazione in astrazione, a botte di dipendenze, finisce per caricare altre 200 classi...

----------

## !equilibrium

 *makoomba wrote:*   

> bah, gli HAL per php non mi hanno mai convinto,

 

HAL? Hardware Abstraction Layer? ma non stavamo parlando di DB Abstraction Layer? oppure ho capito male io ...

 *makoomba wrote:*   

> in secondo luogo, ma non meno importante, ciucciano troppe risorse e spesso senza una reale necessitï¿½.specialmente PEAR.... di astrazione in astrazione, a botte di dipendenze, finisce per caricare altre 200 classi...

 

PEAR non carica 200 classi, forse ti 'installa' in locale 200 classi, ma Ã¨ una cosa completamente diversa...

comunque non sta a me convincerti di nulla, io ho solo dato un'indicazione, non ho detto che gli Abstraction Layer per i DB sono la panacea di tutti i mali.

----------

## makoomba

 *DarkAngel76 wrote:*   

> HAL? Hardware Abstraction Layer? ma non stavamo parlando di DB Abstraction Layer? oppure ho capito male io ...

 

no no, ho scritto una cazzata io, intendevo AL

 *DarkAngel76 wrote:*   

> PEAR non carica 200 classi, forse ti 'installa' in locale 200 classi, ma Ã¨ una cosa completamente diversa...
> 
> comunque non sta a me convincerti di nulla, io ho solo dato un'indicazione, non ho detto che gli Abstraction Layer per i DB sono la panacea di tutti i mali.

 

generalmente, ogni pacchetto in PEAR dipende da almeno un altro paio di classi.

carichi il primo e l'albero comincia a ramificarsi...

anch'io esprimo un semplice parere da (ex) utilizzatore, senza alcuna presunzione di proselitismo.

----------

## !equilibrium

 *makoomba wrote:*   

> generalmente, ogni pacchetto in PEAR dipende da almeno un altro paio di classi.
> 
> carichi il primo e l'albero comincia a ramificarsi...
> 
> anch'io esprimo un semplice parere da (ex) utilizzatore, senza alcuna presunzione di proselitismo.

 

bhe semplicemente non Ã¨ cosÃ¬, forse un tempo, anni fa lo era, ma oramai le dipendenze sono molto basse. e 200 sono praticamente impossibili. Tieni conto che PEAR fa largo uso del Factory Design Pattern, questo vuol dire che anche se un pacchetto ha 10 altre dipendenze, non vuol dire che tutte e 10 ti vengano caricate quanto includi una libreriea del PEAR. tutto qua.

----------

## makoomba

 *DarkAngel76 wrote:*   

> bhe semplicemente non Ã¨ cosÃ¬, forse un tempo, anni fa lo era, ma oramai le dipendenze sono molto basse. e 200 sono praticamente impossibili. Tieni conto che PEAR fa largo uso del Factory Design Pattern, questo vuol dire che anche se un pacchetto ha 10 altre dipendenze, non vuol dire che tutte e 10 ti vengano caricate quanto includi una libreriea del PEAR. tutto qua.

 

non so cosa sia cambiato in un anno, ma ti assicuro che prima di decidermi a scriver ex-novo il mio AL, PEAR l'ho provato a fondo.

200 era tanto per dire, ma la mole di codice che veniva inclusa tentando di utilizzare alcune classi era davvero allucinante.

stesso discorso, ad esempio, per le forms e ho finito per scrivere from-scratch anche quella parte.

non critico il lavoro svolto dagli autori di quei pacchetti, ma da sviluppatore trovo che la quantità di astrazione, in PEAR, sia davvero esagerata.

i pattern vanno utilizzati con criterio, anch'io uso singleton, factory, registry, model view controller, etc etc ma di certo evito l'iterator per ciclare un array.

/me pensa che forse stiamo andando un pò troppo OT

----------

## !equilibrium

 *makoomba wrote:*   

> stesso discorso, ad esempio, per le forms e ho finito per scrivere from-scratch anche quella parte.
> 
> non critico il lavoro svolto dagli autori di quei pacchetti, ma da sviluppatore trovo che la quantitï¿½ di astrazione, in PEAR, sia davvero esagerata.
> 
> /me pensa che forse stiamo andando un pï¿½ troppo OT

 

sulle forms ti do ragione  :Wink: 

ma per l'AL Ã¨ cambiato, quello a cui ti riferisci tu Ã¨ PEAR: :Very Happy: B, io parlo di PEAR::MDB2, comunque si, Ã¨ stato riscritto l'AL proprio per il motivo da te esposto. direi che siamo terribilmente OT (ma almeno per i posteri che cercheranno sul forum la questione sarÃ  chiara   :Laughing:  )

----------

## wildancer

wow, quanta cltura!! non è che qualcuno mi può dire cos'è un database? Va beh scherzo, ma volevo chiedere, per uno che al livello db ha piu o meno una conoscenza zero, dove può iniziare a colmare sta brutta lacuna? io ancora fatico a capire a cosa servono in realtà, è un'argomento che non ho mai affrontato con nessuno ergo oltre alla mole di informazione non so nemmeno cosa li fa preferire ad un foglio di calcolo... So che è strano per voi, ma capitemi, l'unico database con cui ho avuto a che fare è il psd!  :Embarassed: 

----------

## .:chrome:.

se devi iniziare, uno vale l'altro.

comunque le differenze non è che siano abissali, sempre di SQL si tratta.

----------

## GuN_jAcK

@wildancer forse anche conviene guardare con che linguaggio lo vuoi integrare... moli linguaggi hanno un supporto diciamo "magggiore" degli altri.

correggetemi se ho detto una vaccata  :Smile: 

----------

## .:chrome:.

porto un aggiornamento.

sto configurando un mailserver, e tra le altre cose implementa dspam. il training di dspam con backend mySQL ha dato una bella botta alla macchina. passando su postgreSQL è filato via tutto liscissimo, e non mi sembra nemmeno che ci abbia messo di più.

purtroppo è stata una cosa di cui mi sono accorto, non voluta... ma conferma una cosa che ho sempre sentito predicare: postgreSQL non si appesantisce con il crescere delle dimensioni della base di dati, a differenza di mySQL

----------

## Kernel78

 *k.gothmog wrote:*   

> porto un aggiornamento.
> 
> sto configurando un mailserver, e tra le altre cose implementa dspam. il training di dspam con backend mySQL ha dato una bella botta alla macchina. passando su postgreSQL è filato via tutto liscissimo, e non mi sembra nemmeno che ci abbia messo di più.
> 
> purtroppo è stata una cosa di cui mi sono accorto, non voluta... ma conferma una cosa che ho sempre sentito predicare: postgreSQL non si appesantisce con il crescere delle dimensioni della base di dati, a differenza di mySQL

 

Non è che hai anche modo di quantificare il guadagno di tempo ? che dimensione ha la base dati ?

----------

## makoomba

 *k.gothmog wrote:*   

> il training di dspam con backend mySQL ha dato una bella botta alla macchina. passando su postgreSQL è filato via tutto liscissimo, e non mi sembra nemmeno che ci abbia messo di più.

 

mi pare strano.

mysql_drv è noto essere il backend più veloce e testato (a parte hash_drv che però manca di alcune features come i merged groups).

che versioni dspam/mysql ?

----------

## .:chrome:.

quella di mysql è l'ultima stabile: 4.1.qualcosa

quella di dspam è l'ultima disponibile.

a me non sembra molto strano. gli ho dato in pasto 5000 headers, e ha generato un db di oltre 90 MB  :Very Happy: 

----------

## Kernel78

 *k.gothmog wrote:*   

> 
> 
> a me non sembra molto strano. gli ho dato in pasto 5000 headers, e ha generato un db di oltre 90 MB 

 

Sarà che al lavoro sono abituato a vedere DB da 20 GB e oltre ma 90 MB per me è una miseria...

mysql ha veramente problemi a gestire un db così piccolo ?

Lo chiedo perchè non l'ho mai usato ma pensavo che riuscisse a gestire moli di dati più corpose  :Confused: 

----------

## .:chrome:.

dico solo che l'accesso è rallentato al crescere del db, il carico della macchina è aumentato, e l'utilizzo di memoria pure.

poi fai tu

----------

## Kernel78

 *k.gothmog wrote:*   

> dico solo che l'accesso è rallentato al crescere del db, il carico della macchina è aumentato, e l'utilizzo di memoria pure.
> 
> poi fai tu

 

Alla faccia del giocattolo, è una ciofeca  :Shocked: 

Non riesco a spiegarmi come abbia potuto diffondersi così tanto un sw così penoso ...

/ME CHE PENSA A WINDOWS

Ok, adesso capisco come sia stato possibile  :Laughing: 

----------

## .:chrome:.

beh... se servono piccole basi di dati, magari quanto basta per tenere in piedi un sito internet.

magari senza relazioni... solo un ammasso di informazioni... come nella maggior parte dei sito web

non è che vada malaccio, per quel genere di utilizzo

----------

## mrfree

 *k.gothmog wrote:*   

> ho anche preso molti riferimenti da un documento del CERN (se non ricordo male) che confrontava mySQL, postgreSQL, e Oracle.

 

k.gothmog, potrebbe essere una lettura interessante... non è che ti ricordi il link?

----------

## makoomba

qui nessun problema con mezzo giga di db e la combo dspam/mysql.

ok finchè si parla di triggers,stored proc, etc etc ma il punto di forza di mysql è sempre stata l'estrema velocità nell'esecuzione di query "non complesse".

dspam, postfix, imap e molte applicazioni web rientrano in questa categoria, per questo mysql è il db opensource più utilizzato.

----------

## .:chrome:.

ma infatti... sono d'accordo.

c'è sicuramente di meglio di mySQL, però bisogna tenere conto anche di cosa di deve fare.

voglio dire... è inutile che mi comri una lamborghini, se poi la uso per andare a comprare il pane.

tuttavia, in ambienti di produzione tendo sempre a non fidarmi. come diceva fedeliallalinea mySQL è così veloce perché è basilare, nelle sue funzioni. il giorno che mi serve qualcosa di più, siamo sicuri che non mi trovi a dover migrare ad un altro DBMS?

----------

## makoomba

imho, il discorso non è legato ad ambiente di produzione o "casalingo", quanto alle necessità dell'applicazione.

la mancanza di features non implica l'inaffidabilità del prodotto: quello che fa mysql lo fa bene.

il problema, semmai, è in quello che non fa e qui mi trovi d'accordo.

per il resto, è un dbserver utilizzato in produzione da moltissime aziende, anche a livello enterprise (lo usa anche google per alcuni servizi)

----------

## fikiz

 *Kernel78 wrote:*   

>  *k.gothmog wrote:*   
> 
> a me non sembra molto strano. gli ho dato in pasto 5000 headers, e ha generato un db di oltre 90 MB  
> 
> Sarà che al lavoro sono abituato a vedere DB da 20 GB e oltre ma 90 MB per me è una miseria...
> ...

 

Manutengo un MySQL da 100 GB e funziona benissimo. E' chiaro che bisogna saperlo configurare...

Ciao!

----------

## Kernel78

 *fikiz wrote:*   

> Manutengo un MySQL da 100 GB e funziona benissimo. E' chiaro che bisogna saperlo configurare...
> 
> 

 

Ok, mi sembrava strano che facesse le bizze con 90 mb ...

Posso chiederti (se hai fatto tu la scelta) cosa ti ha fatto propendere per mysql rispetto, per esempio, a postgresql ?

----------

## fikiz

Effettivamente la scelta non e' stata mia. Chi ha scelto ritiene MySQL di facile gestione, veloce e affidabile e dopo un quasi paio d'anni di lavoro su di esso non posso che confermare.

Non conosco direttamente Postgres, ma tante delle sue caratteristiche non risultano utili per la nostra attivita'. Quello che ci serve e' un database che risponde bene all'SQL standard, offre transazioni con lock a livello di riga, integrita' referenziale, backup consistenti a caldo e MySQL possiede tutte queste caratteristiche.

Trovo comunque molto interessante l'orientamento di Postgres, che a leggere le possibilita' che offre sembra volere copiare Oracle (che conosco bene). E per l'Open Source e' un OTTIMA cosa  :Smile: 

ciao!

----------

## FreeManAtomic

sono un po OT, ma sembre di dbms si tratta, qualcuno (oltre me!) ha usato firebird?

Io ho fatto due progetti (universitari!.. ed ora vado per il terzo lavorativo) con questo dbms e' devo dire di essermi trovato verametne bene, semplice veloce e con SQL92+altro...

Voi l'avete usato?  :Very Happy: 

[benzina sul fuoco mode]

Il mio docente di basi di dati 2 (che non e' un pinco pallino delle basi di dati..) ha detto che alla fine Postgres e' un ottimo dbms per ambiti universitari, ma in campo lavorativo si trova di meglio!

[/benzina sul fuoco mode]

----------

## .:chrome:.

 *FreeManAtomic wrote:*   

> Il mio docente di basi di dati 2 (che non e' un pinco pallino delle basi di dati..) ha detto che alla fine Postgres e' un ottimo dbms per ambiti universitari, ma in campo lavorativo si trova di meglio!

 

questo senza ombra di dubbio, ma è vero per qualunque cosa. diversamente ogni categoria di software avrebbe la sua "killer application".

il fatto che esistano soluzioni diverse è la prova più semplice che ogni contesto (contesto, non categoria) ha un'applicazione che meglio si presta delle altre a svolgere i suoi compiti.

io sono il primo ad usare mySQL per piccoli siti web, o per db che nn necessitano di query complesse o con piccole moli di dati, ma dico anche che si tratta di un giocattolo a cui non affiderei mai dati importanti. ma questa è solo una mia idea.

ad ogni modo... finalmente l'ho ritroxato: http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.pdf

buona lettura

per rincarare la dose, invito a leggere, dopo questo, l'articolo di flameeyes

----------

## fikiz

ma perche' non ci affideresti dati importanti? lo ritieni inaffidabile? ti e' successo di perdere dei dati a causa di MySQL?

----------

## mrfree

 *k.gothmog wrote:*   

> finalmente l'ho ritroxato: http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.pdf
> 
> buona lettura

 

Il documento è praticamente "vuoto", ho provato ad aprirlo sia con evince che con acroread ma non mi pare ci siano tutte le informazioni.

Comunque ho trovato la versione html su google 

Grazie... vado con la lettura  :Wink: 

----------

## fikiz

 *Quote:*   

> Comunque ho trovato la versione html su google 

 

E' un documento piuttosto vecchio: prende in considerazione Oracle 8 (che avra' almeno 6 anni, ma forse di piu') e sostiene che MySQL non supporta foreign key e transazioni (e invece sono disponibili gia' da parecchio).

Credo che se venisse riveduto allo stato attuale sia MySQL che Postgres guadagnerebbero terreno rispetto ad Oracle sulle caratteristiche piu' importanti.

----------

## .:deadhead:.

Date una lettura a questo articolo  :Very Happy:  Five reasons why you should never use PostgreSQL -- ever .

----------

## ercoppa

Domanda da un "ignorantone" come me. Ho visto che postgresql viene rilasciato sotto una particolare licanza(License:     POSTGRESQL), a differenza di una GPL-2 (che se non sbaglio è quella sotto cui viene rilasciato mysql) che restrizioni da?

----------

## .:chrome:.

basta leggere la licenza  :Wink: 

comunque anche mysql viene rilasciato con doppia licenza

----------

## .:deadhead:.

Non conosco la licenza di postres ma i consiglio di andare a leggere questo articolo di un developer di gentoo riguardante mysql :

http://dev.gentoo.org/~flameeyes/articles

----------

## .:chrome:.

 *.:deadhead:. wrote:*   

> Non conosco la licenza di postres ma i consiglio di andare a leggere questo articolo di un developer di gentoo riguardante mysql :
> 
> http://dev.gentoo.org/~flameeyes/articles

 

l'avevo postato all'inizio del thread  :Wink: 

----------

## fedeliallalinea

La licenza con cui e' rilasciato postgresql e' la BSD e non una sua (http://www.postgresql.org/about/licence) che mi e' molto comoda potendolo utilizzare anche per scopi commerciali (visto che lavoro per una ditta in cui ha bisogno un DB)

----------

## Kernel78

 *fedeliallalinea wrote:*   

> La licenza con cui e' rilasciato postgresql e' la BSD e non una sua (http://www.postgresql.org/about/licence) che mi e' molto comoda potendolo utilizzare anche per scopi commerciali (visto che lavoro per una ditta in cui ha bisogno un DB)

 

Piccolo OT ma a quanto mi risulta puoi usare per scopi commerciali anche software sotto GPL (altrimenti suse eredhat andrebbero in fallimento)...

----------

## fedeliallalinea

 *Kernel78 wrote:*   

> Piccolo OT ma a quanto mi risulta puoi usare per scopi commerciali anche software sotto GPL (altrimenti suse eredhat andrebbero in fallimento)...

 

No loro ci guadagnano sull'assistenza, se una ditta vuole fare un prodotto colsed source con mysql integrato non puo' perche' se uso un programma gpl allora anche il mio software diventa automaticamente gpl (mentre se fosse lgpl la storia cambia). Comunque per usare mysql per scopo commerciale non vale la gpl ma subentra un'altra licenza che devi pagare.

----------

## Kernel78

 *fedeliallalinea wrote:*   

>  *Kernel78 wrote:*   Piccolo OT ma a quanto mi risulta puoi usare per scopi commerciali anche software sotto GPL (altrimenti suse eredhat andrebbero in fallimento)... 
> 
> No loro ci guadagnano sull'assistenza, se una ditta vuole fare un prodotto colsed source con mysql integrato non puo' perche' se uso un programma gpl allora anche il mio software diventa automaticamente gpl (mentre se fosse lgpl la storia cambia). Comunque per usare mysql per scopo commerciale non vale la gpl ma subentra un'altra licenza che devi pagare.

 

Ok, non mi era chiaro l'utilizzo commerciale che ne fai ...

----------

