MySQL è al capolinea?

[WizOfOz]

Salviamo MySQL! » Gli utenti pagheranno le spese

[andrea.paiola]

oh ma siete fissati... usate postgresql e non rompete i maroni

[WizOfOz]

Si tu la fai facile... ma pensa alle migliaia di applicazioni o siti che si appoggiano a MySQL... se dovesse veramente accadere sarebbe una cosa devastante per il mondo opensource.
Inoltre Postgres non è sotto licenza GNU ma sotto licenza BSD e si dice che sia più lento di MySQL se non ottimizzato. Non è semplice come scegliere che scarpe mettere (sempre che sia semplice anche scegliere le scarpe

[Uno]

Si tu la fai facile... ma pensa alle migliaia di applicazioni o siti che si appoggiano a MySQL... se dovesse veramente accadere sarebbe una cosa devastante per il mondo opensource.
Inoltre Postgres non è sotto licenza GNU ma sotto licenza BSD e si dice che sia più lento di MySQL se non ottimizzato. Non è semplice come scegliere che scarpe mettere (sempre che sia semplice anche scegliere le scarpe

Beh che abbia la licenza sotto BSD non c'è nulla di male, quasi la preferisco.
Sulle performance ammetto di non avere esperienza o aver mai fatto test approfonditi, ma dicono che sia peggio su lavori piccoli e su lavori rapidi ma molto meglio per archivi grandi, lavori continuati etc... insomma se parliamo di siti grandi e trafficati con una buona cachè dovrebbe esser meglio, forse anche parecchio.
Ma ripeto che parlo per sentito dire.
In moltissime applicazioni web il passaggio potrebbe essere praticamente indolore. Diverso il discorso se c'è stata una progettazzione del db specifica per Mysql.

[WizOfOz]

In moltissime applicazioni web il passaggio potrebbe essere praticamente indolore.

Non credo più a Babbo Natale e alle migrazioni indolore

[Uno]

Non credo più a Babbo Natale e alle migrazioni indolore

Dai... se è un forum (esempio stupido, ma vale per un cms e tutto) che usa un db abstraction layer, ti basta solo travasare i dati del db mysql in uno pgsql con identica struttura e fare lo switch sul file di configurazione.
Invece sicuramente ci saranno applicazione che anche se usano un db abstraction layer non possono essere semplicemente travasate, ma la maggior parte delle comuni applicazioni web (forum, cms, ecommerce etc) si.

P.s. non credi più a Babbo Natale perchè a te che sei cattivo non ti porta i regali

[WizOfOz]

Dai... se è un forum (esempio stupido, ma vale per un cms e tutto) che usa un db abstraction layer, ti basta solo travasare i dati del db mysql in uno pgsql con identica struttura e fare lo switch sul file di configurazione.

Ma io penso a tutti quei poveretti che usano una applicazione già fatta e non sono in grado do mettere mano a un file di configurazione.. in ogni caso è una cosa che porta via un sacco di tempo... immagina chi hosta applicazioni basate su MySQL e ad un tratto deve migrare un intero parco clienti a una nuova versione dell'applicazione..

P.s. non credi più a Babbo Natale perchè a te che sei cattivo non ti porta i regali

Anche questo è vero

[DonChisciotte]

dalle notizie che ho io, al momento della notizia dell'acquisizione di mysql da parte di sun, Michael "Monty" Widenius decise di creare un progetto alternativo per fare in modo che non ci potessero essere problemi di licenza.
il nuovo database si chiama Maria e lo scopo del progetto e' - cito testualmente - "To provide a community developed, stable, and always Free branch of MySQL that is, on the user level, compatible with the main version. We strive for total interoperability with our upstreams and our own community."

per quanto riguarda postgresql, la migrazione non sarebbe certamente facile, ne' indolore.
d'altronde, non si puo' essere schiavi di un unico database (percio' io solitamente tendo all'utilizzo di pgsql al posto di mysql, ovviamente non sono ascoltato quasi mai).

ciao e siamo davvero agli sgoccioli: buon anno nuovo!

[Kuro]

ecco perchè sono un sostenitore di PDO che, sintassi delle query a parte, permette un veloce cambio di engine

[guest]

Mi aggancio: su pdo manca una cosa secondo me fondamentale (o meglio, non sono riuscito a trovarla): come diavolo si fa a visualizzare un prepared statement già processato con i vari bind param?

Praticamente la query pronta da essere eseguita...

[GrG]

Se davvero mancasse comunque sarebbero due righe di codice, lo metti in buglist e in due ore la hai

Io comunque come ho già detto non mi preoccupo, MySQL resterà tra noi in eterno. Farlo sparire sarebbe un suicidio per Oracle, ci perderebbe solo.

Secondo me l'unica cosa che rischiano sono i branch. Probabilmente non vorranno che ci siano progetti paralleli, e forse stringeranno la licenza per farli sparire.

[Kuro]

Mi aggancio: su pdo manca una cosa secondo me fondamentale (o meglio, non sono riuscito a trovarla): come diavolo si fa a visualizzare un prepared statement già processato con i vari bind param?

Praticamente la query pronta da essere eseguita...

non si può. la sostituzione bind - param avviene contestualmente all'esecuzione della query (con execute())

perchè? cosa devi fare di preciso?

[guest]

In caso di errore, siamo soliti a copiare/incollare la query su strumenti di sviluppo esterni in modo da fare i test dal di li, piuttosto che direttamente lato PHP.

Inoltre, farebbe comodo avere la query 'as-is' da essere processata ad esempio con EXPLAIN e cose simili o eventuali ottimizzatori.
Non avere la query elaborata a disposizione rallenta lo sviluppo, in certi casi.

[Kuro]

debugDumpParams() non ti è sufficiente?
se pdo genera una exception, sono quasi sicuro che potresti trovare qualcosa nel backtrace.

comunque stai parlando di ambiente di sviluppo o produzione?

[guest]

Parlo sia di sviluppo che produzione.
Il debugDumpParams l'ho usato una volta è mi ha tirato fuori millemila righe. Peccato, un "asSQL" sulla falasariga di "asXML" presente in simplexml sarebbe stato perfetto.