Discussion:
Usare il db giusto, non quello sbagliato
(too old to reply)
unknown
2013-07-11 08:52:41 UTC
Permalink
[cross-posted su python-it e django-it]

È passato un po' di tempo, è ora di rinfocolare vecchie polemiche. :-)

Non ci sono grandi novità su MySQL: è l'orrendo cesso di sempre, è ancora
in mano a Oracle, i fork open hanno futuro incerto, speriamo si levi di
mezzo prima possibile.

Ma vien fuori ancora gente che non sente la puzza, è utile levare i tappi
dal naso.


Ci sono abbondanti discussioni negli archivi [di python-it], ma oggi ho
notato un post su Google+, purtroppo privato, di un mio ex-collega, con
un commento di un altro mio ex-collega. Entrambi hanno lavorato per MySQL
AB per anni. Sono tra le persone tecnicamente più in gamba che conosco.
Inizio del post:

"I worked at #MySQL AB for a few years, fixing problems full time, and I
still have no idea why it's attractive to people. I think they hired me
because I was so unhappy with it and said I thought PostgreSQL was better
in every way that mattered.

As a programmer, I think we should learn from some of the mistakes that
MySQL made. [snip]"

Segue dettagliata descrizione di vari problemi.

Fine del commento del secondo:

"[snip] I definitely run postgres everywhere I can now :)? "

Non servono commenti.


Parlando di PostgreSQL, sono di ritorno da EuroPython 2013, settimana
scorsa a Firenze, e sto cercando di rimettere la mascella a posto. Ero
rimasto un po' indietro, ci hanno messo dentro veramente di tutto.

Una panoramica di molte delle nuove feature:

Postgres Demystified
<https://ep2013.europython.eu/conference/talks/postgres-demystified>

Come usare le nuove feature nell'ORM di Django:

Going beyond the Django ORM limitations with Postgres
<https://ep2013.europython.eu/conference/talks/going-beyond-the-django-orm-limitations-with-postgres>

Ci sono altri tre talk su Python e PostgreSQL, questi son quelli che ho
seguito.


Non c'era un solo talk su MySQL. Che vuoi raccontare, che fa schifo?
Ormai s'è capito.


(I video dei talk non sono ancora sulle pagine dei talk, ma li trovate su
YouTube: <http://www.youtube.com/user/PythonItalia>.

Ovviamente prima di tutto occorre rendere omaggio agli infaticabili
organizzatori, soprattutto il tesoriere, quello con la maglia rossa:

--
Nicola Larosa - http://www.tekNico.net/
unknown
2013-07-11 09:09:01 UTC
Permalink
In realta` c'e` stato un talk su MongoDB.

--
<https://www.yoùtube.com/watch?v=URJeuxI7kHo>
unknown
2013-07-11 11:25:29 UTC
Permalink
Post by unknown
Post by unknown
Non c'era un solo talk su MySQL. Che vuoi raccontare, che fa schifo?
Ormai s'è capito.
In realta` c'e` stato un talk su MongoDB.
Che vuoi dire, che sarebbe il MySQL dei database NoSQL? Quello è CouchDb. :-P
--
Nicola Larosa - http://www.tekNico.net/

Le principali aziende statunitensi hanno speso in attività di lobbying
molto più di quanto abbiano versato in tasse federali. [...] Queste
tangenti sono del tutto legali. Le imprese pagano non per violare
la legge, ma per farsi approvare leggi a proprio uso e consumo.
- Comidad, novembre 2012
unknown
2013-07-11 19:06:58 UTC
Permalink
Post by unknown
In realta` c'e` stato un talk su MongoDB.
Anche lui mi sta deludendo parecchio, almeno lato amministrativo. Oggi,
dopo due ore, mongodump era ancora al 1% per dumpare una collezione di
17mln di record. Cercando in giro informazioni in merito, tutti
entravano in modalita` supercazzola, dando la colpa ai dischi o, in
generale, alla macchina, tanto che i workaround piu` gettonati erano
fsync + snapshot lvm oppure start replica, stop replica, backup replica.
Per ora il mio giudizio rimane ancora in modalita` meh, vedremo come matura

Enrico
unknown
2013-07-11 19:24:12 UTC
Permalink
2013/7/11 Enrico Bianchi <enrico.bianchi a ymail.com>
Post by unknown
Anche lui mi sta deludendo parecchio, almeno lato amministrativo. Oggi,
dopo due ore, mongodump era ancora al 1% per dumpare una collezione di
17mln di record. Cercando in giro informazioni in merito, tutti entravano
in modalita` supercazzola, dando la colpa ai dischi o, in generale, alla
macchina, tanto che i workaround piu` gettonati erano fsync + snapshot lvm
oppure start replica, stop replica, backup replica. Per ora il mio giudizio
rimane ancora in modalita` meh, vedremo come matura
Non ho ancora fatto mai un dump ma essendo testuale una compressione
brutale no? Tipo un tar.gz del file ? Chiedo da ignorante, non ho ancora
abbastanza esperienza sui backup di Mongo.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/8450a118/attachment.html>
unknown
2013-07-12 19:56:47 UTC
Permalink
Post by unknown
Non ho ancora fatto mai un dump ma essendo testuale una compressione
brutale no? Tipo un tar.gz del file ? Chiedo da ignorante, non ho
ancora abbastanza esperienza sui backup di Mongo.
No, mongodump genera un BSON della collection. In teoria e`
comprimibile, ma il problema e` proprio l'estrazione (oggi, alle 14,
dopo 24 ore era ancora al 19%)

Enrico
unknown
2013-07-12 20:02:31 UTC
Permalink
2013/7/12 Enrico Bianchi <enrico.bianchi a ymail.com>
No, mongodump genera un BSON della collection. In teoria e` comprimibile,
ma il problema e` proprio l'estrazione (oggi, alle 14, dopo 24 ore era
ancora al 19%)
Ma quanti dati sono? In termini di dimensioni intendo.

Ciao
--
Andrea Francia http://andreafrancia.it
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/867deeae/attachment.html>
unknown
2013-07-12 20:19:01 UTC
Permalink
2013/7/12 Enrico Bianchi <enrico.bianchi a ymail.com>
No, mongodump genera un BSON della collection. In teoria e` comprimibile,
ma il problema e` proprio l'estrazione (oggi, alle 14, dopo 24 ore era
ancora al 19%)
Io non mi sono spiegato bene, al posto di MongoDump fare un tar.bz del file
di Mongo.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/507bf124/attachment.html>
unknown
2013-07-11 09:21:27 UTC
Permalink
Post by unknown
[cross-posted su python-it e django-it]
È passato un po' di tempo, è ora di rinfocolare vecchie polemiche. :-)
Non ci sono grandi novità su MySQL: è l'orrendo cesso di sempre, è ancora
in mano a Oracle, i fork open hanno futuro incerto, speriamo si levi di
mezzo prima possibile.
[...]
"I worked at #MySQL AB for a few years, fixing problems full time, and I
still have no idea why it's attractive to people. I think they hired me
because I was so unhappy with it and said I thought PostgreSQL was better
in every way that mattered.
As a programmer, I think we should learn from some of the mistakes that
MySQL made. [snip]"
Segue dettagliata descrizione di vari problemi.
Hai saltato proprio la parte più interessante...
Post by unknown
[...]
Ciao Manlio
unknown
2013-07-11 09:59:34 UTC
Permalink
" I think they hired me
because I was so unhappy with it and said I thought PostgreSQL was better
in every way that mattered.
Nicola non è che stai cercando di farti assumere anche tu ? ;) ;)

G
unknown
2013-07-11 11:18:21 UTC
Permalink
Post by unknown
Post by unknown
As a programmer, I think we should learn from some of the mistakes
that MySQL made. [snip]"
Segue dettagliata descrizione di vari problemi.
Hai saltato proprio la parte più interessante...
Lo so, ma come ho detto era un messaggio privato, non posso citare tutti
i dettagli. Potrei provare a chiedere il permesso al mio ex-collega.
Forse avrei già dovuto farlo, in effetti. :-)
--
Nicola Larosa - http://www.tekNico.net/

Le principali aziende statunitensi hanno speso in attività di lobbying
molto più di quanto abbiano versato in tasse federali. [...] Queste
tangenti sono del tutto legali. Le imprese pagano non per violare
la legge, ma per farsi approvare leggi a proprio uso e consumo.
- Comidad, novembre 2012
unknown
2013-07-11 09:23:14 UTC
Permalink
2013/7/11 Nicola Larosa <nico a teknico.net>
Post by unknown
È passato un po' di tempo, è ora di rinfocolare vecchie polemiche. :-)
Quali? Scusa Nicola ma io non vedo sostenitori di MySql se non tra i
lamerazzi che fanno sitarelli in PHP (meglio ancora con Joomla o Wordpress
(la moda del momento) usando magari un ide/editor Adobe a caso.

Che Postgres sia non solo superiore (di brutto) a MySql, ma addirittura
possa tranquillamente essere una valida alternativa a Oracle, non sono io
ad affermarlo ma gente ben piu' in gamba di me.

Se volevi scatenare un flame (vista 'estate fresca che stiamo avendo posso
capire il perche') potevi scegliere argomenti tipo meglio Pyton2.x o
Python3.x ;)

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/65117772/attachment.html>
unknown
2013-07-11 11:23:46 UTC
Permalink
Post by unknown
Post by unknown
È passato un po' di tempo, è ora di rinfocolare vecchie polemiche. :-)
Quali?
Quelle vecchie, appunto. :-)
Post by unknown
Scusa Nicola ma io non vedo sostenitori di MySql
Su questa lista stamattina:

"ho un database Mysql"
Post by unknown
Se volevi scatenare un flame (vista l'estate fresca che stiamo avendo
posso capire il perche')
Volevo solo rinfocolare vecchie polemiche. ;-)

E fornire qualche puntatore a degli utili talk che ho visto. E magari far
notare a qualcuno che forse non sta facendo il miglior servizio a sé e ai
propri utenti.
--
Nicola Larosa - http://www.tekNico.net/

Le principali aziende statunitensi hanno speso in attività di lobbying
molto più di quanto abbiano versato in tasse federali. [...] Queste
tangenti sono del tutto legali. Le imprese pagano non per violare
la legge, ma per farsi approvare leggi a proprio uso e consumo.
- Comidad, novembre 2012
unknown
2013-07-11 14:15:22 UTC
Permalink
2013/7/11 Nicola Larosa <nico a teknico.net>
Post by unknown
"ho un database Mysql"
Si ma era una richiesta di aiuto, del tipo "sta male, non sopravvivera',
aiutatemi a risparmiargli atroci tormenti" ;)

E fornire qualche puntatore a degli utili talk che ho visto.


Cosa di cui ti sono grato, visto che pure quest'anno mi sono dovuto perdere
la PyCon (per me ormai e' la PySenza)
Post by unknown
E magari far
notare a qualcuno che forse non sta facendo il miglior servizio a sé e ai
propri utenti.
Beh se non ci arriva da se temo che sia come tentare di convertire al
buddhismo un Testimone di Geova. ;)

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/1f310759/attachment.html>
unknown
2013-07-11 12:19:15 UTC
Permalink
Il giorno 11/lug/2013 11:24, "Carlos Catucci" <carlos.catucci a gmail.com> ha
Post by unknown
2013/7/11 Nicola Larosa <nico a teknico.net>
Post by unknown
È passato un po' di tempo, è ora di rinfocolare vecchie polemiche. :-)
Quali? Scusa Nicola ma io non vedo sostenitori di MySql se non tra i
lamerazzi che fanno sitarelli in PHP (meglio ancora con Joomla o Wordpress
(la moda del momento) usando magari un ide/editor Adobe a caso.
Sostenitore no... ma utilizzatore sì... e per un semplice motivo... uso
wordpress (si... e per quello che devo fare mi va più che bene)... ho
scelto Aruba come fornitore di servizi, e fino ad ora non me ne sono mai
pentito... poco problemi, e quando cui sono stati quei pochi, l'assistenza
mi ha risposto e risolto il problema in poche ore... in italiano... ed il
costo è contenuto... con spazio web illimitato. Probabilmente se fossi
un'azienda con altri budget e altri target, farei altre scelte...
soprattutto ora che ho conosciuto python. Va da se che con le scelte fatte
era ed è d'obbligo la scelta di MySQL.

Anni fa avevo provato in locale plone... un vero delirio, ora non so a che
punto è arrivato... se è più facile come gestione. Fatto sta che non cui
sono fornitori di servizi web (italiani) che ti forniscono python ad un
prezzo concorrenziale con quello di Aruba... (ripeto, per un uso home è una
cosa importante).
Post by unknown
Che Postgres sia non solo superiore (di brutto) a MySql, ma addirittura
possa tranquillamente essere una valida alternativa a Oracle, non sono io
ad affermarlo ma gente ben piu' in gamba di me.
Su questo non ci posso mettere becco... siete stati voi a distruggermi
maisiquel, ed ancora non ho avuto modo di provare postgres.

Ma prima o poi....

Byez.
--
Gollum1
tessssoro, dov'è il mio tessssoro...
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/11358a99/attachment.html>
unknown
2013-07-11 19:16:16 UTC
Permalink
Post by unknown
Su questo non ci posso mettere becco... siete stati voi a distruggermi
maisiquel, ed ancora non ho avuto modo di provare postgres.
Qua ti posso rispondere io. Query complessa con un fottiliardo di inner
join del tipo "WHERE t1.campo = t2.campo" in mezzo, non modificabile
perche` generata da un simil orm. Su MySQL (5.1 se non ricordo male, ma
e` un problema anche in 5.5), su macchina virutale pompata linux 64bit,
il database ci metteva un'ora per tirare fuori i dati. Su Oracle 11g, su
macchina fisica pompata linux 64bit, ci metteva 5 minuti. Su PostgreSQL
(una 9.0 o una 9.1, non ricordo), su macchina virutale windows (2003
32bit, 1 core e 512Mb di RAM allocati) ci ha messo 7 minuti

Enrico
P.S. ovviamente la base dati era la stesa migrata sui tre db
unknown
2013-07-11 19:19:21 UTC
Permalink
2013/7/11 Enrico Bianchi <enrico.bianchi a ymail.com>

Qua ti posso rispondere io. Query complessa con un fottiliardo di inner
Post by unknown
join del tipo "WHERE t1.campo = t2.campo" in mezzo, non modificabile
perche` generata da un simil orm. Su MySQL (5.1 se non ricordo male, ma e`
un problema anche in 5.5), su macchina virutale pompata linux 64bit, il
database ci metteva un'ora per tirare fuori i dati. Su Oracle 11g, su
macchina fisica pompata linux 64bit, ci metteva 5 minuti. Su PostgreSQL
(una 9.0 o una 9.1, non ricordo), su macchina virutale windows (2003 32bit,
1 core e 512Mb di RAM allocati) ci ha messo 7 minuti
Credo tu sia passabile di non so quale richiesta di risarcimento.

Mi pare che Oracle vieti espressamente di pubblicare benchmark che
riguardano i suoi prodotti (chissà se è leggenda o no). A me questo
basterebbe per squalificare un'intero marchio.

Ciao.
Marco.
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/5992776b/attachment-0001.html>
unknown
2013-07-11 19:20:09 UTC
Permalink
2013/7/11 Marco Beri <marcoberi a gmail.com>
Post by unknown
Credo tu sia passabile di non so quale richiesta di risarcimento.
Ehm... passibilie... :-)
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/65abb141/attachment.html>
unknown
2013-07-12 20:19:47 UTC
Permalink
Post by unknown
Mi pare che Oracle vieti espressamente di pubblicare benchmark che
riguardano i suoi prodotti (chissà se è leggenda o no). A me questo
basterebbe per squalificare un'intero marchio.
Si, lo vieta. Ma un paragone del genere non so quanto sia dannoso per
Oracle (alla fine ho detto che ha vinto), senza contare che ora dovrebbe
esere vietato anche su MySQL (non so, sinceramente non ho indagato su
questo fronte)

Enrico

unknown
2013-07-11 19:29:12 UTC
Permalink
2013/7/11 Enrico Bianchi <enrico.bianchi a ymail.com>
Post by unknown
Qua ti posso rispondere io. Query complessa con un fottiliardo di inner
join del tipo "WHERE t1.campo = t2.campo" in mezzo, non modificabile
perche` generata da un simil orm. Su MySQL (5.1 se non ricordo male, ma e`
un problema anche in 5.5), su macchina virutale pompata linux 64bit, il
database ci metteva un'ora per tirare fuori i dati. Su Oracle 11g, su
macchina fisica pompata linux 64bit, ci metteva 5 minuti. Su PostgreSQL
(una 9.0 o una 9.1, non ricordo), su macchina virutale windows (2003 32bit,
1 core e 512Mb di RAM allocati) ci ha messo 7 minuti
Come benchmark non male. E dimostra come non stiamo dicendo cazzate.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/350eb908/attachment-0001.html>
unknown
2013-07-11 19:09:28 UTC
Permalink
Post by unknown
Quali? Scusa Nicola ma io non vedo sostenitori di MySql se non tra i
lamerazzi che fanno sitarelli in PHP
Eh, magari, io vedo ancora professionisti che ti rispondono candidamente
"il problema e` tuo perche` non lo sai usare" :/

Enrico
unknown
2013-07-11 19:13:46 UTC
Permalink
2013/7/11 Enrico Bianchi <enrico.bianchi a ymail.com>
Post by unknown
Eh, magari, io vedo ancora professionisti che ti rispondono candidamente
"il problema e` tuo perche` non lo sai usare" :/
Scusate le domande ma non ho la vostra esperienza in DB.
1) Ma questi problemi di MySQL di cui parlate si riferiscono solo alle
prestazioni o c'e' altro, tipo affidabilità, strutture dati supportati?
2) Con quanti tabelle/record/GB si cominciano a sentire i problemi di cui
parlate.

Grazie
--
Andrea Francia http://andreafrancia.it
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/80156d91/attachment.html>
unknown
2013-07-11 19:28:10 UTC
Permalink
Post by unknown
1) Ma questi problemi di MySQL di cui parlate si riferiscono solo alle
prestazioni o c'e' altro, tipo affidabilità, strutture dati supportati?
Entrambi. Il planner di MySQL e` parecchio sensibile a come scrivi la
query, o meglio se non la scrivi come dice lui il planner scazza e di
brutto (senza contare che lo fa sia in ordinamento che in caso di
viste). Lato amministrativo, l'ultimo esempio l'ho avuto durante la
conversione del db in UTF-8. Praticamente, dopo aver eseguito il dump
testuale ed averlo convertito in UTF-8, al momento del restore,
nonostente passassi al client l'opzione per inviare pacchetti di 32Mb al
database, mi resettava la connessione senza un errore chiaro. Solo dopo
parecchi tentativi ho capito che il problema era che non prendeva il
parametro del client ma che dovevo impostarlo sul my.cnf (quel giorno ho
fatto piangere Cthulhu)
Post by unknown
2) Con quanti tabelle/record/GB si cominciano a sentire i problemi di
cui parlate.
Anche pochi, il discorso e` che se vuoi usare proficuamente MySQL devi
progettare uno schema semplice (ovvero poca normalizzazione e tante flat
table)

Enrico
unknown
2013-07-11 19:27:46 UTC
Permalink
2013/7/11 Enrico Bianchi <enrico.bianchi a ymail.com>
Post by unknown
Eh, magari, io vedo ancora professionisti che ti rispondono candidamente
"il problema e` tuo perche` non lo sai usare" :/
Per me non sono professionali ergo per estensione non sono professionisti.
Li inquadro nella precedente categoria. Se uno invece di portare argomenti
cerca di cavarsela dicendo "e' perche' non sai usarlo" per me si squalifica
subito. E uno cosi' in un progetto non ce lo voglio.

S e' vero ultimamente sono diventato selettivo (tagliato un paio di persone
per scarsa professionalita' proprio in questi giorni) ma cazzo se dopo devi
perdere tempo per stare dietro a scelte implementative che non reputo
valide (se mi sbaglio lo ammetto, ma se poi ho ragione chi ci mette
riparo?), sorry lasciamo stare, il mondo e' grade abbastanza da lasciare
spazio per tutti.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/eb008f14/attachment.html>
unknown
2013-07-11 11:43:07 UTC
Permalink
Post by unknown
Ci sono abbondanti discussioni negli archivi [di python-it], ma oggi ho
notato un post su Google+, purtroppo privato, di un mio ex-collega, con
un commento di un altro mio ex-collega. Entrambi hanno lavorato per MySQL
AB per anni. Sono tra le persone tecnicamente più in gamba che conosco.
Non ho idea dei commenti tecnici ma ricordo il perche' tanto tempo fa
cominciai usando mysql (oggi sinceramente dei db non me ne importa
praticamente piu' nulla):

2. si integrava con php ed apache *facilmente*
3. la documentazione c'era ed era di altissima qualita' (parliamo di
pre 2000)
4. funzionava a sufficienza

Postgres allora sembrava "esoterico" e la documentazione ... beh c'era
se sapevi gia' come funzionava ed inoltre non c'era "nessuno" in giro a
spiegarmi nulla (internet esisteva solo all'universita' o col modem e
google non esisteva!!!).
Post by unknown
"I worked at #MySQL AB for a few years, fixing problems full time, and I
still have no idea why it's attractive to people. I think they hired me
because I was so unhappy with it and said I thought PostgreSQL was better
in every way that mattered.
As a programmer, I think we should learn from some of the mistakes that
MySQL made. [snip]"
Questo commento (spero non fuori contesto) e' davvero risibile: la
gente che lo ha assunto l'ha fatto "ragionando" che gli serviva qualcuno
competente (tecnicamente). Forse non ci e' ancora arrivato (magari
dovrebbe imparare qualcosa anche dai successi di mysql);)

Quando si deve decidere una piattaforma
integrazione/documentazione/semplicita' sono i punti principali. Seguono
ad una discreta distanza ragioni tecniche (e solo se hanno un impatto
sul prodotto finale).
Post by unknown
Non c'era un solo talk su MySQL. Che vuoi raccontare, che fa schifo?
Ormai s'è capito.
Se qualcuno mi desse un euro per ogni volta che incontro software che
fa' schifo non ci sarebbero piu' euri in giro.
unknown
2013-07-11 13:06:56 UTC
Permalink
2013/7/11 <a.cavallo a cavallinux.eu>
Quando si deve decidere una piattaforma integrazione/documentazione/**semplicita'
sono i punti principali. Seguono ad una discreta distanza ragioni tecniche
(e solo se hanno un impatto sul prodotto finale).
Mi pare inutile voler difendere scelte del passato, nessuno le discute.

Mi spiego meglio:

Nicola: "è pazzo e sciocco usare oggi la programmazione a schede perforate".
A.Cavallo: "non è come dici, ai tempi c'era solo quella, non era così male,
era ben documentata".

Ecco, leggendo la tua risposta ho avuto questa stessa impressione :-)

Il messaggio di Nicola è molto chiaro e ficcante: al giorno d'oggi non ha
senso scegliere MySQL per un progetto che nasce.
Inoltre ha anche molto senso pensare di migrare eventuali progetti verso
Postgresql.

Fine del discorso (che condivido in toto).

Ciao.
Marco.
P.S. Hai Wordpress su Mysql? Chissenefrega, continua a usarlo e amen. Non
si parla di questo in una lista Python-it ;-)
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/c5a6b3c1/attachment.html>
unknown
2013-07-11 13:21:15 UTC
Permalink
Post by unknown
Ecco, leggendo la tua risposta ho avuto questa stessa impressione :-)
A me invece è apparsa un'enorme insegna al neon lampeggiante stile Las
Vegas con su scritto:

SINDROME DI STOCCOLMA

Vabe', sempre meglio della madonna.
Post by unknown
Fine del discorso (che condivido in toto).
Marco, mi fa specie che tu non commenti il link in fondo al mio messaggio
in cui si evidenzia la serietà e il rigore degli organizzatori. Mi sembra
il minimo.
--
Nicola Larosa - http://www.tekNico.net/
unknown
2013-07-11 13:37:31 UTC
Permalink
2013/7/11 Nicola Larosa <nico a teknico.net>
Post by unknown
Marco, mi fa specie che tu non commenti il link in fondo al mio messaggio
in cui si evidenzia la serietà e il rigore degli organizzatori. Mi sembra
il minimo.
Chi si loda s'imbroda... :-D
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/ee549268/attachment.html>
unknown
2013-07-11 12:38:27 UTC
Permalink
Post by unknown
[cross-posted su python-it e django-it]
È passato un po' di tempo, è ora di rinfocolare vecchie polemiche. :-)
In ogni gruppo che si rispetti ci vuole un po' di flame :)
unknown
2013-07-11 13:55:25 UTC
Permalink
Post by unknown
Quali? Scusa Nicola ma io non vedo sostenitori di MySql se non tra i
lamerazzi che fanno sitarelli in PHP (meglio ancora con Joomla o Wordpress
(la moda del momento) usando magari un ide/editor Adobe a caso.
Che Postgres sia non solo superiore (di brutto) a MySql, ma addirittura
possa tranquillamente essere una valida alternativa a Oracle, non sono io
ad affermarlo ma gente ben piu' in gamba di me.
Se volevi scatenare un flame (vista 'estate fresca che stiamo avendo posso
capire il perche') potevi scegliere argomenti tipo meglio Pyton2.x o
Python3.x ;)
Carlos
Non è la prima volta che in questa lista leggo interventi come
questo, e mi permetto di dire che sono
*quantomeno* ingiusti, se non addirittura sbagliati e fuorvianti.

Premetto -molto modestamente- che, sia grazie agli studi
universitari, sia grazie a vari percorsi privati e di autodidatta,
conosco ed utilizzo svariati linguaggi, e cerco di tenermi quanto
più aggiornato possibile dedicando molto tempo,
ancora oggi, allo studio, compatibilmente alle esigenze lavorative.
Insomma, cerco di parlare con cognizione di causa.

IMHO ritengo che Mysql, PostgreSQL e Oracle siano completamente
differenti, e quindi che la scelta dipenda dal progetto che si sta
affrontando.
Non conosco personalmente/lavorativamente chi fa queste
affermazioni, ma mi sembra giusto portare
i miei "2 cents" a beneficio dei giovani che leggono:
nel 2013 non è il linguaggio o il database che si utilizza che fa di
te un "lamerozzo", ma *come* lo si sceglie,
*come* lo si configura e *come* si utilizza. Consigliare il cliente
e guidarlo in base alle sue priorità:
scalabilità, velocità di realizzo, costi di
sviluppo/gestione,ambiente di produzione,... chi se la sente di dire che
esiste una soluzione valida sempre?
Personalmente possiamo avere delle preferenze, e magari la nostra
attività lavorativa ci porta maggiormente a
fare delle scelte, ma sono soggettive e non generalizzabili.


Alberto









-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/89bd4def/attachment.html>
unknown
2013-07-11 14:04:18 UTC
Permalink
2013/7/11 Alberto De Prezzo <albertodeprezzo a gmail.com>
Post by unknown
IMHO ritengo che Mysql, PostgreSQL e Oracle siano completamente
differenti, e quindi che la scelta dipenda dal progetto che si sta
affrontando.
Non conosco personalmente/lavorativamente chi fa queste affermazioni, ma
mi sembra giusto portare
nel 2013 non è il linguaggio o il database che si utilizza che fa di te un
"lamerozzo", ma *come* lo si sceglie,
*come* lo si configura e *come* si utilizza. Consigliare il cliente e
scalabilità, velocità di realizzo, costi di sviluppo/gestione,ambiente di
produzione,... chi se la sente di dire che
esiste una soluzione valida sempre?
Non sono d'accordo con quanto dici (ma mi batterò fino alla morte affinché
tu possa dirlo, ecc. :-)

Ad oggi per operare un ginocchio si fa il primo taglio usando un
bisturi. Ad oggi se serve un nuovo database si deve usare Postgresql.

Fine del discorso. Davvero è così semplice.

In passato non era così, in futuro probabilmente le cose cambieranno. Ma
per ora non serve dire altro.

Poi ci sono questioni legacy o politiche. Ma tecnicamente non c'è molto
altro da aggiungere.

Ciao.
Marco.
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/c5b85ab8/attachment.html>
unknown
2013-07-11 14:31:57 UTC
Permalink
2013/7/11 Marco Beri <marcoberi a gmail.com>
Post by unknown
Ad oggi per operare un ginocchio si fa il primo taglio usando un
bisturi. Ad oggi se serve un nuovo database si deve usare Postgresql.
Fine del discorso. Davvero è così semplice.
In passato non era così, in futuro probabilmente le cose cambieranno. Ma
per ora non serve dire altro.
Poi ci sono questioni legacy o politiche. Ma tecnicamente non c'è molto
altro da aggiungere.
+1
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/a17a0ba0/attachment.html>
unknown
2013-07-11 14:47:04 UTC
Permalink
2013/7/11 Marco Beri <marcoberi a gmail.com>
Post by unknown
Ad oggi per operare un ginocchio si fa il primo taglio usando un
bisturi. Ad oggi se serve un nuovo database si deve usare Postgresql.
Io per adesso me la sono cavata con file csv e quando l'ho incontrato
sqlite.
Sono giocattolini, ma per le mie esigenze vanno benone.

Sarà per questo che la brutta ferita al ginocchio non guarisce mai ;-))

E' un piacere leggervi, mentre vi "scannate", ops... "confrontate"


Il giorno 11 luglio 2013 16:31, Carlos Catucci
Post by unknown
2013/7/11 Marco Beri <marcoberi a gmail.com>
Post by unknown
Ad oggi per operare un ginocchio si fa il primo taglio usando un
bisturi. Ad oggi se serve un nuovo database si deve usare Postgresql.
Fine del discorso. Davvero è così semplice.
In passato non era così, in futuro probabilmente le cose cambieranno. Ma
per ora non serve dire altro.
Poi ci sono questioni legacy o politiche. Ma tecnicamente non c'è molto
altro da aggiungere.
+1
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
_______________________________________________
Python mailing list
Python a lists.python.it
http://lists.python.it/mailman/listinfo/python
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/e495db76/attachment.html>
unknown
2013-07-11 14:49:21 UTC
Permalink
Il giorno 11/lug/2013 16:47, "Alberto Abate" <alberto.abate a gmail.com> ha
Post by unknown
2013/7/11 Marco Beri <marcoberi a gmail.com>
Post by unknown
Ad oggi per operare un ginocchio si fa il primo taglio usando un
bisturi. Ad oggi se serve un nuovo database si deve usare Postgresql.
Post by unknown
Io per adesso me la sono cavata con file csv e quando l'ho incontrato
sqlite.
Post by unknown
Sono giocattolini, ma per le mie esigenze vanno benone.
Un bisturi non serve per una sbucciatura :-)
Post by unknown
Sarà per questo che la brutta ferita al ginocchio non guarisce mai ;-))
E' un piacere leggervi, mentre vi "scannate", ops... "confrontate"
Lol!

L'informatico è l'unico professionista che vuole diffondere e regalare i
propri vantaggi competitivo-tecnologici.

Che strano individuo... :-)

Ciao.
Marco.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/1f9d8659/attachment.html>
unknown
2013-07-11 14:52:28 UTC
Permalink
E' solo un reperto archeologico, ma ve lo ricordate?

https://pypi.python.org/pypi/KirbyBase

Il sito non c'è più, ma mi ricordo che l'idea mi era piaciuta molto...
Cioè un db costruito con soli file txt.
Era prima di scoprire il modulo csv.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/33c80d2a/attachment.html>
unknown
2013-07-11 18:20:26 UTC
Permalink
Post by unknown
2013/7/11 Alberto De Prezzo <albertodeprezzo a gmail.com>
IMHO ritengo che Mysql, PostgreSQL e Oracle siano completamente differenti, e quindi che la scelta dipenda dal progetto che si sta affrontando.
Non conosco personalmente/lavorativamente chi fa queste affermazioni, ma mi sembra giusto portare
nel 2013 non è il linguaggio o il database che si utilizza che fa di te un "lamerozzo", ma come lo si sceglie,
scalabilità, velocità di realizzo, costi di sviluppo/gestione,ambiente di produzione,... chi se la sente di dire che
esiste una soluzione valida sempre?
Non sono d'accordo con quanto dici (ma mi batterò fino alla morte affinché tu possa dirlo, ecc. :-)
Ad oggi per operare un ginocchio si fa il primo taglio usando un bisturi. Ad oggi se serve un nuovo database si deve usare Postgresql.
Fine del discorso. Davvero è così semplice.
In passato non era così, in futuro probabilmente le cose cambieranno. Ma per ora non serve dire altro.
Poi ci sono questioni legacy o politiche. Ma tecnicamente non c'è molto altro da aggiungere.
Ciao.
Marco.
La verità è che PostgreSQL ha un nome orrendo.
Vuoi mettere come suona figo 'Oracle' ?
Come suona confidenziale 'MySql' ?

Ma come gli è venuto in mente un nome così orrendo che mette 4 consonanti 'stgr'
che ti si accartoccia la lingua a dirlo, e quel inizio 'Post' che ricorda
Postmoderno, Postriblo, Postergare (ebbene sì, anche postergare è una parola che non amo).

E con ciò chiudo perché altri difetti in PostgreSQL non riesco a trovarne.
E a corollario c'è pure psycopg che grazie a (San) Daniele è ora praticamente perfetto.

G
unknown
2013-07-11 20:10:25 UTC
Permalink
Post by unknown
La verità è che PostgreSQL ha un nome orrendo.
Vuoi mettere come suona figo 'Oracle' ?
Come suona confidenziale 'MySql' ?
Secondo me un'altra questione e' che eoni fa MySQL girava su Windows,
PostgreSQL no.
Pare che qualche sviluppatore all'epoca non si fosse accorto della
superiorita' di Unix come piattaforma di sviluppo e stesse ancora su
Windows.

--
.
..: -enrico-
unknown
2013-07-11 20:13:23 UTC
Permalink
Post by unknown
Secondo me un'altra questione e' che eoni fa MySQL girava su Windows,
PostgreSQL no.
Pare che qualche sviluppatore all'epoca non si fosse accorto della
superiorita' di Unix come piattaforma di sviluppo e stesse ancora su
Windows.
Come non fare un "full quote" ?!?.
unknown
2013-07-11 20:25:56 UTC
Permalink
2013/7/11 enrico franchi <enrico.franchi a gmail.com>
Post by unknown
Pare che qualche sviluppatore all'epoca non si fosse accorto della
superiorita' di Unix come piattaforma di sviluppo e stesse ancora su
Windows.
Ce ne sono ancora di quelli la. Volevano rinchiuderli in un isola che
diventava un parco a tema sul Giurassico, ma catturarli non e' cosi' facile
;)

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/6d0bd215/attachment-0001.html>
unknown
2013-07-11 23:21:25 UTC
Permalink
Quiz della serata, il "bogobenchmark"

C'è una tabella con 10 colonne e 20 milioni di righe.
Tutti numeri interi 32 bit, prima colonna pkey consecutiva e gli altri
random.
Su ogni colonna c'è un indice.

La domanda è: quanto tempo impiega, rispettivamente su mysql e postgres, il
DROP INDEX dell'ultima colonna?
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/2286623a/attachment.html>
unknown
2013-07-12 13:29:41 UTC
Permalink
Post by unknown
Quiz della serata, il "bogobenchmark"
C'è una tabella con 10 colonne e 20 milioni di righe.
Tutti numeri interi 32 bit, prima colonna pkey consecutiva e gli altri
random.
Su ogni colonna c'è un indice.
La domanda è: quanto tempo impiega, rispettivamente su mysql e postgres, il
DROP INDEX dell'ultima colonna?
Non so rispondere alla tua domanda, ma sono curioso. Qual'e` il tuo usecase?

Intendo: in 25 anni di amministrazione di DB di ogni tipo e dimensione
non mi e` mai capitato che DROP INDEX mi cadesse all'interno di una
sezione critica dal punto di vista prestazionale, e mi stupirebbe
alquanto che l'ottimizzare quell'operazione in tal senso sia una
priorita` in qualsiasi database relazionale...

Cheers,

--
© 2013
::

R
K-<M>-S
L
unknown
2013-07-12 13:40:19 UTC
Permalink
Post by unknown
Non so rispondere alla tua domanda, ma sono curioso. Qual'e` il tuo usecase?
Intendo: in 25 anni di amministrazione di DB di ogni tipo e dimensione
non mi e` mai capitato che DROP INDEX mi cadesse all'interno di una
sezione critica dal punto di vista prestazionale, e mi stupirebbe
alquanto che l'ottimizzare quell'operazione in tal senso sia una
priorita` in qualsiasi database relazionale...
Diventa una priorità nel momento in cui, per eseguire il drop di un indice,
viene creata una tabella nuova, copiandone il contenuto dalla vecchia, per
poi ricostruire tutti gli N-1 indici e sostuituire la tabella vecchia con
la nuova.

No, non ho controllato il comportamento su versioni recenti. La mia
esperienza risale al 2010.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/899ffd3f/attachment.html>
unknown
2013-07-12 14:53:37 UTC
Permalink
Post by unknown
Post by unknown
Non so rispondere alla tua domanda, ma sono curioso. Qual'e` il tuo usecase?
Diventa una priorità nel momento in cui, per eseguire il drop di un indice,
viene creata una tabella nuova, copiandone il contenuto dalla vecchia, per
poi ricostruire tutti gli N-1 indici e sostuituire la tabella vecchia con la
nuova.
AAAARRGGHH, ero riuscito a rimuovere questa cosa, e tu ora me l'hai
fatta ricordare :(

Essi` che ho anche tenuto un corso di MySQL per i tipi di Telecom Lab
di Trento, non piu` di 3 anni fa (alla fine del quale, nelle note di
feedback, la maggior parte dei partecipanti ha scritto tipo:
"insegnante bravo, ma si nota che MySQL non gli piace" :P).

E nonostante i miei amici trolloni continuino inutilmente ad
endorsarmi MySQL su LinkedIn <Loading Image... :P

--
© 2013
::

R
K-<M>-S
L
unknown
2013-07-12 15:00:16 UTC
Permalink
Post by unknown
AAAARRGGHH, ero riuscito a rimuovere questa cosa, e tu ora me l'hai
fatta ricordare :(
La cosa più stupefacente fu vedere lo stesso comportamento (una valanga di
GB occupati, ore di tempo) per cambiare un default in NOT NULL.

Credo sia infine stato sistemato con la 5.1:

bugs.mysql.com/bug.php?id=2364
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/c30b1a19/attachment-0001.html>
unknown
2013-07-12 15:06:50 UTC
Permalink
Basta guardare il video per non usare + MySQL




Per approfondimenti:

http://sql-info.de/mysql/gotchas.html
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/fd1e58c6/attachment.html>
unknown
2013-07-12 16:00:05 UTC
Permalink
2013/7/12 Carlo Miron <miron a python.it>
Post by unknown
E nonostante i miei amici trolloni continuino inutilmente ad
endorsarmi MySQL su LinkedIn <http://i.imgur.com/3WTNKLh.png?1> :P
Ora che lo so ... mi dai il tuo contatto linkedin che ti endorso? ;)

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/3200ccf8/attachment.html>
unknown
2013-07-11 14:31:01 UTC
Permalink
2013/7/11 Alberto De Prezzo <albertodeprezzo a gmail.com>
Post by unknown
IMHO ritengo che Mysql, PostgreSQL e Oracle siano completamente
differenti, e quindi che la scelta dipenda dal progetto che si sta
affrontando.
Che siano differenti e' evidente, che Postgres possa andare bene tanto per
progetti piu' piccoli (dove di solito si usa MySql) che per piu' grandi
(dove Oracle regnava quasi incontrastato) e' provato con i fatti, che la
scelta dipende dal progetto ... diciamo dal progettista.

Posto che io affermo sempre che il miglior linguaggio/sistema
operativo/editor/IDE/quant'altro sia quello che sai usare meglio, ci sono
delel oggettivita' che non si possono soggettivitizzare (e cheido scusa per
i neologismi orrendi).
Post by unknown
Non conosco personalmente/lavorativamente chi fa queste affermazioni, ma
mi sembra giusto portare
nel 2013 non è il linguaggio o il database che si utilizza che fa di te un
"lamerozzo", ma *come* lo si sceglie,
*come* lo si configura e *come* si utilizza.
La scelta pero' viene fatta in base all'esperienza. E chi ha esperienza e
non ha idee fossilizzate (io sono bravo a usare il cobol quindi il prossimo
gioco grafico 3D realtime lo scrivo in cobol, che e' il miglior linguaggio
del mondo [*] ) scegliera' in base alle effettive prestazioni.
Ora, concordo che per andare per fossi sia meglio una jeep che una ferrari
testarossa, pero' potrei anche usare una Panda 4x4 al suo posto.
MySql ha dei limiti evidenti. La sua capillare diffusione, al pari del
linguaggio che piu' di ogni altro e' il suo sposo perfetto (PHP) e' legata
sopratutto a due fattori:

1. Piu' semplice da amministrare a livello power user di altri
2. Praticamente spesso la sola scelta offerta da gran parte degli host (chi
ha detto aruba?)

Ma siamo alla logica del "mangiate merda, milioni di miliardi di mosche non
possono avere torto" (ovvero se lo usano in tanti deve esserci qualcosa di
buono).
Post by unknown
scalabilità, velocità di realizzo, costi di sviluppo/gestione,ambiente di
produzione,... chi se la sente di dire che
esiste una soluzione valida sempre?
Non stiamo dicendo che esiste la soluzione valida sempre, ma che certe cose
da te descritte puo' offrirle di certo Postgres e non puo' fare altrettanto
MySql.

E te lo dice uno che usava MySql gia' 10 anni e passa fa' (come vola il
tempo quando fai un lavoro che ti diverte).
Post by unknown
Personalmente possiamo avere delle preferenze, e magari la nostra attività
lavorativa ci porta maggiormente a
fare delle scelte, ma sono soggettive e non generalizzabili.
Forse lo farai tu. Io scelgo (se posso, altrimenti "consiglio" caldamente,
fino al punto di rifiutare di fare il lavoro se il caso) sempre la
soluzione migliore in se, oggettivamente.
Poi che ci siano casi in cui mi chiedono di fare una applicazione PHP con
db MsSqServer, che girera' su 3 PC posti nello stesso ufficio dove 2 sono
solo delle postazioni di scorta, praticamente neppure lavoreranno mai 2
assieme, e rifiutano la mia proposta di sviluppare il tutto in C# .NET, il
tutto perche' i ragazzotti del CED del cliente finale vogliono PHP perche'
una volta hanno stampato Ciao Mondo ... beh ciascuno butta via i soldi come
meglio crede, certo, e come diceva Barnum "Ogni minuto nasce un pollo", ma
questo non vuol dire che una cosa bacata non sia tale in casi particolari.


* Per alcune cose specifiche potrebbe anche essere vero, sebbene non me ne
sovvenga nessuna in questo momento, probabilmente un mio limite.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/43f8a9ef/attachment-0001.html>
unknown
2013-07-11 19:37:41 UTC
Permalink
Post by unknown
1. Piu' semplice da amministrare a livello power user di altri
'Sta cosa me la dovete spiegare: cos'ha di cosi` semplice da
amministrare PostgreSQL?

Enrico
unknown
2013-07-11 18:56:39 UTC
Permalink
Non è la prima volta che in questa lista leggo interventi come questo, e mi
permetto di dire che sono
*quantomeno* ingiusti, se non addirittura sbagliati e fuorvianti.
Ottimo! Per esempio perche'?
Premetto -molto modestamente- che, sia grazie agli studi universitari, sia
grazie a vari percorsi privati e di autodidatta,
conosco ed utilizzo svariati linguaggi, e cerco di tenermi quanto più
aggiornato possibile dedicando molto tempo,
ancora oggi, allo studio, compatibilmente alle esigenze lavorative. Insomma,
cerco di parlare con cognizione di causa.
Bravissimo. Ora pero' vogliamo sentire cosa ne pensi.
IMHO ritengo che Mysql, PostgreSQL e Oracle siano completamente differenti,
e quindi che la scelta dipenda dal progetto che si sta affrontando.
Per esempio, per cosa useresti MySQL? E in particolare, per quale
motivo lo trovi piu' indicato di PostgreSQL in quegli ambiti?
Consigliare il cliente e guidarlo
scalabilità, velocità di realizzo, costi di sviluppo/gestione,ambiente di
produzione,... chi se la sente di dire che
esiste una soluzione valida sempre?
A me sembra che in tutte queste categorie MySQL finisca ben peggio di
PostgreSQL, con la possibile eccezione dell'ambiente di produzione...
non ho idea se qualcuno usi Postgres su server windows. Su server
Linux mi sembra che non ci sia paragone.
Personalmente possiamo avere delle preferenze, e magari la nostra attività
lavorativa ci porta maggiormente a
fare delle scelte, ma sono soggettive e non generalizzabili.
Non tutto e' relativo, pero'.

--
.
..: -enrico-
unknown
2013-07-11 19:45:13 UTC
Permalink
Post by unknown
scalabilità, velocità di realizzo, costi di sviluppo/gestione,ambiente
di produzione,... chi se la sente di dire che esiste una soluzione
valida sempre?
Io: PostgreSQL :)

Enrico
P.S. rispondo qua perche` non ho voglia di scrivere un'altra email ;)
MySQL lo uso tutti i giorni, cosi` come uso tutti i giorni anche
MongoDB, Oracle, SQL Server e PostgreSQL. E, ribadisco, preferirei molto
di piu` andare ad usare solo quest'ultimo e, al massimo, Oracle
piuttosto che MySQL
unknown
2013-07-11 19:55:11 UTC
Permalink
P.S. rispondo qua perche` non ho voglia di scrivere un'altra email ;) MySQL lo uso tutti i giorni,
Uhh? mi spiace...
SQL Server ?
Cavolo, e da quando? Mannaggia? mi spiace davvero tanto? (mancava solo che usassi anche Access e stavi apposto !-)
unknown
2013-07-11 15:29:51 UTC
Permalink
Post by unknown
Non sono d'accordo con quanto dici (ma mi batterò fino alla morte affinché
tu possa dirlo, ecc. :-)
:)
Post by unknown
Ad oggi per operare un ginocchio si fa il primo taglio usando un
bisturi. Ad oggi se serve un nuovo database si deve usare Postgresql.
Fine del discorso. Davvero è così semplice.
In passato non era così, in futuro probabilmente le cose cambieranno. Ma
per ora non serve dire altro.
Poi ci sono questioni legacy o politiche. Ma tecnicamente non c'è molto
altro da aggiungere.
Ciao.
Marco.
Chiarisco una cosa: lungi da me fare il difensore di MySQL, sono il
primo a *preferire* Postgres,
pero' non sarei così estremista. Non si rifiuta un lavoro perché c'è MySQL

IMHO, MySQL -se ben configurato ed amministrato- ad oggi non è questo
demonio che descrivete.
Ritengo che negli anni Postgres verrà fuori meglio e si farà preferire,
ma chi vivrà vedrà.
Sono convinto che allo stato attuale non possiamo definirlo una
soluzione sempre-e-comunque superiore.

p.s.: Una piccola curiosità: da quale versione non usate MySQL?

Alberto
unknown
2013-07-11 17:45:06 UTC
Permalink
2013/7/11 Alberto De Prezzo <albertodeprezzo a gmail.com>
Post by unknown
pero' non sarei così estremista. Non si rifiuta un lavoro perché c'è MySQL
Non ho detto che rifiuto per MySql, ma se assieme a mysql trovo altre cose
che non mi convincono ...
Post by unknown
IMHO, MySQL -se ben configurato ed amministrato- ad oggi non è questo
demonio che descrivete.
No e' un demonio, ma non ha senso in ottica professionale, non molta piu'
di usare ad esempio Access.

Ritengo che negli anni Postgres verrà fuori meglio e si farà preferire,
Post by unknown
ma chi vivrà vedrà.
Se guardi in giro i progetti importanti trovi ovunque Postgres o i NoSql
(Mongo, Hadoop etc.). MySql sempre piu rimane la scelta dello sviluppatore
semi-pro che non ha voglia/capacita'/necessita' di fare il salto di
qualita'.

Sono convinto che allo stato attuale non possiamo definirlo una
Post by unknown
soluzione sempre-e-comunque superiore.
Pareri. Strettamente personali. Io pero' guardo ai fatti,, e come diceva
l'assessore Cevoli: e i fatti lo dimostrano! ;)

p.s.: Una piccola curiosità: da quale versione non usate MySQL?

Ultima mi sembra sia stata 5.1 o poco piu'.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/0a107d29/attachment-0001.html>
unknown
2013-07-11 18:18:30 UTC
Permalink
Post by unknown
Se guardi in giro i progetti importanti trovi ovunque Postgres o i NoSql
(Mongo, Hadoop etc.). MySql sempre piu rimane la scelta dello sviluppatore
semi-pro che non ha voglia/capacita'/necessita' di fare il salto di
qualita'.
Siccome non mi sembrano dei pirla, mi chiedevo come mai in Google
usano MySql per Cloud SQL [1]

[1] https://developers.google.com/cloud-sql/faq

ciao
--
Gian Mario Tagliaretti
GNOME Foundation member
gianmt a gnome.org
unknown
2013-07-11 18:21:05 UTC
Permalink
Il giorno 11/lug/2013 20:18, "Gian Mario Tagliaretti" <
Post by unknown
Post by unknown
Se guardi in giro i progetti importanti trovi ovunque Postgres o i NoSql
(Mongo, Hadoop etc.). MySql sempre piu rimane la scelta dello sviluppatore
semi-pro che non ha voglia/capacita'/necessita' di fare il salto di
qualita'.
Siccome non mi sembrano dei pirla, mi chiedevo come mai in Google
usano MySql per Cloud SQL [1]
[1] https://developers.google.com/cloud-sql/faq
Penso per lo stesso motivo per cui in Facebook usano PHP. Legacy.

E comunque non è che sono tutti infallibili lì, eh... :-)

Ciao.
Marco.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/b40308c1/attachment.html>
unknown
2013-07-11 18:48:30 UTC
Permalink
Post by unknown
Il giorno 11/lug/2013 20:18, "Gian Mario Tagliaretti"
Post by unknown
Siccome non mi sembrano dei pirla, mi chiedevo come mai in Google
usano MySql per Cloud SQL [1]
[1] https://developers.google.com/cloud-sql/faq
Penso per lo stesso motivo per cui in Facebook usano PHP. Legacy.
Ma in realtà il servizio non è uno dei più antichi, anzi direi che è
relativamente nuovo, pensandola esattamente come la maggiornanza dei
presenti su MySql mi son chiesto già da un po' il perchè di questa
scelta
Post by unknown
E comunque non è che sono tutti infallibili lì, eh... :-)
Ahhh su questo non c'è dubbio, sono parecchie le scelte di Google che
non condivido, o più semplicemente non comprendo, ultimamente (ma
purtroppo o per fortuna non gestico il loro wallet)

ciao
--
Gian Mario Tagliaretti
GNOME Foundation member
gianmt a gnome.org
unknown
2013-07-11 19:10:02 UTC
Permalink
2013/7/11 Gian Mario Tagliaretti <g.tagliaretti a gmail.com>
Post by unknown
Post by unknown
Penso per lo stesso motivo per cui in Facebook usano PHP. Legacy.
Ma in realtà il servizio non è uno dei più antichi, anzi direi che è
relativamente nuovo, pensandola esattamente come la maggiornanza dei
presenti su MySql mi son chiesto già da un po' il perchè di questa
scelta
Ah, non lo sapevo.
Confesso di aver risposto senza controllare (infatti ho scritto "penso" :-).
Post by unknown
E comunque non è che sono tutti infallibili lì, eh... :-)
Ahhh su questo non c'è dubbio, sono parecchie le scelte di Google che
non condivido, o più semplicemente non comprendo, ultimamente (ma
purtroppo o per fortuna non gestico il loro wallet)
:-)

Ciao.
Marco.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/59813646/attachment.html>
unknown
2013-07-11 19:41:43 UTC
Permalink
Post by unknown
pensandola esattamente come la maggiornanza dei
presenti su MySql mi son chiesto già da un po' il perchè di questa
scelta
Perche` probabilmente hanno preso in esame altri fattori, tra cui la
diffusione, che ha generato parecchie librerie e parecchi software di
contorno

Enrico
unknown
2013-07-11 18:57:28 UTC
Permalink
2013/7/11 Marco Beri <marcoberi a gmail.com>
Post by unknown
Penso per lo stesso motivo per cui in Facebook usano PHP.
... perché così possono usare phpMyAdmin!

Ciao
--
Andrea Francia http://andreafrancia.it
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/281ebc8d/attachment-0001.html>
unknown
2013-07-11 19:10:59 UTC
Permalink
2013/7/11 Andrea Francia <andrea a andreafrancia.it>
Post by unknown
2013/7/11 Marco Beri <marcoberi a gmail.com>
Post by unknown
Penso per lo stesso motivo per cui in Facebook usano PHP.
... perché così possono usare phpMyAdmin!
LOL
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/48cdebdf/attachment.html>
unknown
2013-07-11 19:22:56 UTC
Permalink
2013/7/11 Andrea Francia <andrea a andreafrancia.it>
Post by unknown
Penso per lo stesso motivo per cui in Facebook usano PHP.
... perché così possono usare phpMyAdmin!
+1 LOL
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/0f2e54b1/attachment.html>
unknown
2013-07-11 19:30:49 UTC
Permalink
Post by unknown
2013/7/11 Andrea Francia <andrea a andreafrancia.it>
Penso per lo stesso motivo per cui in Facebook usano PHP.
... perché così possono usare phpMyAdmin!
+1 LOL
Ari-LOL :D
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/3d3e2426/attachment.html>
unknown
2013-07-11 20:14:51 UTC
Permalink
Post by unknown
Siccome non mi sembrano dei pirla, mi chiedevo come mai in Google
usano MySql per Cloud SQL [1]
Legacy. Lo hanno usato da tanto (alcuni a suo tempo credo che
raccontarono pure perche' ci finirono -- iirc per motivi abbastanza
trasversali -- ora di loro non si sa piu' nulla[0]).

Inoltre se hai la forza lavoro di Google, il fatto che una soluzione
sia piu' incasinata da gestire e' verosimilmente irrilevante (hai
programmatori di livello altissimo, in numero altissimo).


---
[0] probabilmente la loro esistenza digitale era contenuta proprio su
MySQL, e, tanto per cambiare, i dati sono andati persi.

--
.
..: -enrico-
unknown
2013-07-11 19:32:45 UTC
Permalink
Post by unknown
2013/7/11 Alberto De Prezzo <albertodeprezzo a gmail.com>
pero' non sarei così estremista. Non si rifiuta un lavoro perché c'è MySQL
Non ho detto che rifiuto per MySql, ma se assieme a mysql trovo altre cose che non mi convincono ?
Beh, tipicamente insieme a MySQL oramai si trova sempre più solo roba PHP?. per cui, basta farsi due conti!
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/359403be/attachment.html>
unknown
2013-07-11 19:35:04 UTC
Permalink
2013/7/11 Valerio Maggio <valerio.maggio a gmail.com>
Post by unknown
Beh, tipicamente insieme a MySQL oramai si trova sempre più solo roba
PHP?. per cui, basta farsi due conti!
Dai PHP non e' il massimo ma adesso associarlo a MySql .... ;P

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/22ab0f6d/attachment.html>
unknown
2013-07-11 19:29:47 UTC
Permalink
Post by unknown
Ero
rimasto un po' indietro, ci hanno messo dentro veramente di tutto.
E` stato fatto notare che praticamente puoi usare PostgreSQL anche come
e al posto di un NoSQL? :)

Enrico
unknown
2013-07-11 19:31:59 UTC
Permalink
2013/7/11 Enrico Bianchi <enrico.bianchi a ymail.com>
E` stato fatto notare che praticamente puoi usare PostgreSQL anche come e
al posto di un NoSQL? :)
Si lo ho sentito dire ma mi chiedo: la feature piu' interessante di
MongoDb, ovvero non dover definire una struttura rigida delle tabelle, e
poter mescolare alla cazzo campi eterogenei aggiungendone e sottraendone a
piacimento da record a record, e' possibile?
Se dite di si prendo in considerazione di divorziare e sposarlo ;)

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/6d9a1923/attachment.html>
unknown
2013-07-11 19:52:56 UTC
Permalink
Si lo ho sentito dire ma mi chiedo: la feature piu' interessante di MongoDb, ovvero non dover definire una struttura rigida delle tabelle, e poter mescolare alla cazzo campi eterogenei aggiungendone e sottraendone a piacimento da record a record, e' possibile?
Se dite di si prendo in considerazione di divorziare e sposarlo ;)
Beh, non ti posso rispondere con esattezza perché non ho letto/visto il talk, ma credo che il paragone sia stato fatto più in termini di performance che non in termini di "strutturazione del dato".

PostgreSQL resta (e rimarrà, IMHO) la reference per i DBMS *relazionali*.
Non credo abbiano intenzione di "snaturarlo" tramutandolo in un ibrido "no strutturato"/NOSQL?

In ogni caso, anche se solo in termini di performance, il confronto mi sembrerebbe davvero molto interessante.

In teoria, utilizzare un DBMS relazionale normalizzato produce, inevitabilmente, un degrado delle performance per query "complesse" in cui si è costretti ad effettuare join multiple.

Uno dei vantaggi, invece, (sempre in teoria) di un database schema-less è che i dati li hai senza una struttura pre-impostata e con una miglioramenti delle prestazioni in termini di latenza e throughput (ragione per cui big-data sono al giorno d'oggi spesso sinonimo di NoSQL).

Ora però, mi chiedo, quanto era "affidabile" il benchmark? (considerando già il fatto che un benchmark, di per se, non porta a conclusioni generali !-)
unknown
2013-07-11 20:23:13 UTC
Permalink
2013/7/11 Valerio Maggio <valerio.maggio a gmail.com>
Post by unknown
PostgreSQL resta (e rimarrà, IMHO) la reference per i DBMS *relazionali*.
Non credo abbiano intenzione di "snaturarlo" tramutandolo in un ibrido "no
strutturato"/NOSQL?
Mi sta bene, era solo che non dover usare due oggetti diversi per esigenze
(a volte) mixed-up era una specie di sogno, ma si sa poi si aprono gli
occhi e si va a lavorare. E ti trovi PHP con SqlServer su architettura m$.
;P

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/26a1df6c/attachment.html>
unknown
2013-07-11 19:55:44 UTC
Permalink
Post by unknown
Post by unknown
E` stato fatto notare che praticamente puoi usare PostgreSQL anche
come e al posto di un NoSQL? :)
Hai voglia. :-)
Post by unknown
Si lo ho sentito dire ma mi chiedo: la feature piu' interessante di
MongoDb, ovvero non dover definire una struttura rigida delle tabelle,
e poter mescolare alla cazzo campi eterogenei aggiungendone e
sottraendone a piacimento da record a record, e' possibile?
Ci sono vari modi.

C'è hstore che è un repository chiave-valore generico e interrogabile
nelle query.

C'è un campo JSON che dalla 9.3 sarà anche lui interrogabile
internamente. Includeranno perfino V8, l'interprete Javascript di Chrome. :-)

Poi si può accedere a database NoSQL esterni ed integrarli nelle query, e
credo altri modi ancora.

Hanno veramente esagerato. :-)
--
Nicola Larosa - http://www.tekNico.net/

Le principali aziende statunitensi hanno speso in attività di lobbying
molto più di quanto abbiano versato in tasse federali. [...] Queste
tangenti sono del tutto legali. Le imprese pagano non per violare
la legge, ma per farsi approvare leggi a proprio uso e consumo.
- Comidad, novembre 2012
unknown
2013-07-11 19:58:24 UTC
Permalink
Post by unknown
Ci sono vari modi.
C'è hstore che è un repository chiave-valore generico e interrogabile
nelle query.
C'è un campo JSON che dalla 9.3 sarà anche lui interrogabile
internamente. Includeranno perfino V8, l'interprete Javascript di Chrome. :-)
Poi si può accedere a database NoSQL esterni ed integrarli nelle query, e
credo altri modi ancora.
Hanno veramente esagerato. :-)
Che spettacolo!!

P.s. Grazie per la segnalazione dei talk!-)
unknown
2013-07-11 20:24:36 UTC
Permalink
2013/7/11 Nicola Larosa <nico a teknico.net>
Post by unknown
C'è hstore che è un repository chiave-valore generico e interrogabile
nelle query.
C'è un campo JSON che dalla 9.3 sarà anche lui interrogabile
internamente. Includeranno perfino V8, l'interprete Javascript di Chrome. :-)
Poi si può accedere a database NoSQL esterni ed integrarli nelle query, e
credo altri modi ancora.
Hanno veramente esagerato. :-)
Wowowowow!!!!!! Appena finisco le cose che sto facendo mi scarico il
manuale completo e so cosa leggere nei prossimi giorni.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130711/864b93e6/attachment.html>
unknown
2013-07-11 23:31:51 UTC
Permalink
Post by unknown
Post by unknown
Si lo ho sentito dire ma mi chiedo: la feature piu' interessante di
MongoDb, ovvero non dover definire una struttura rigida delle
tabelle,
e poter mescolare alla cazzo campi eterogenei aggiungendone e
sottraendone a piacimento da record a record, e' possibile?
Ci sono vari modi.
C'è hstore che è un repository chiave-valore generico e interrogabile
nelle query.
C'è un campo JSON che dalla 9.3 sarà anche lui interrogabile
internamente. Includeranno perfino V8, l'interprete Javascript di Chrome. :-)
Poi si può accedere a database NoSQL esterni ed integrarli nelle query, e
credo altri modi ancora.
Ciao,

al flame non partecipo, mi sembra piuttosto gratuito.

Volevo solo segnalarvi che giusto domani ho un talk al PGDay UK su
Psycopg. No, non chiedo se ci siete, immagino sia tardino :) Ma tra gli
argomenti che tocco c'è giusto come integrare queste nuove feature in
Python (json, hstore...) È solo una sorvolata sugli argomenti: tutti i
dettagli sono nel manuale. Ma se uno non sa che una feature esiste non
se la cerca nel manuale, giusto?

Lo slideshow è già online su
<https://github.com/dvarrazzo/psycopg-pgdayuk-2013>. Contiene anche una
demo che considero gustosa: come inviare segnali asincroni dal database
direttamente ai browser web (ed essendo lo slideshow in html, la demo
effettua un push direttamente da psql allo slideshow :). Beh, anche lo
slideshow è interessante in sè, visto che è scritto in reST... Insomma,
se volete date pure un'occhiata: c'è più di uno spunto (sia riguardo
Postgres che altro).
--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
unknown
2013-07-12 06:50:49 UTC
Permalink
2013/7/12 Daniele Varrazzo <piro a develer.com>
Post by unknown
al flame non partecipo, mi sembra piuttosto gratuito.
E fai bene.

Però ci penso io a farti partecipare citando una tua slide :-)

"People moves from PHP to Python looking for a more sane environment pretty
much as MySQL people start using Postgres when they grow up."


Volevo solo segnalarvi che giusto domani ho un talk al PGDay UK su Psycopg.
Post by unknown
No, non chiedo se ci siete, immagino sia tardino :) Ma tra gli argomenti
che tocco c'è giusto come integrare queste nuove feature in Python (json,
hstore...) È solo una sorvolata sugli argomenti: tutti i dettagli sono nel
manuale. Ma se uno non sa che una feature esiste non se la cerca nel
manuale, giusto?
Lo slideshow è già online su <https://github.com/dvarrazzo/**
psycopg-pgdayuk-2013 <https://github.com/dvarrazzo/psycopg-pgdayuk-2013>>.
Contiene anche una demo che considero gustosa: come inviare segnali
asincroni dal database direttamente ai browser web (ed essendo lo slideshow
in html, la demo effettua un push direttamente da psql allo slideshow :).
Beh, anche lo slideshow è interessante in sè, visto che è scritto in
reST... Insomma, se volete date pure un'occhiata: c'è più di uno spunto
(sia riguardo Postgres che altro).
Come sempre, grazie mille. Interessantissime.

Tre note veloci da nitpicker :-)

1) Il suggerimento che hai dato per diagnosticare gli idle a me non
funziona:

pippo=> select * from pg_stat_activity where current_query ~ '<IDLE> in';
ERROR: column "current_query" does not exist
LINE 1: select * from pg_stat_activity where current_query ~ '<IDLE>...

Dove toppo?

2) Nella slide dove citi Little Bobby Tables mi sa che hai scritto "second"
ma intendevi "first" nel commento finale.

cur.execute("select * from blah where key = '" + key + "'") #
BADcur.execute("select * from blah where key = %s", [key])) # GOOD

What to do if your developer writes code in the *second* style? Don't shout
at him, don't break his heart: he has only one. Break him a bone: he's got
206.

3) Infine nella slide sul typecasting mi sa che hai lasciato indentato a
destra le presenter notes (o così pare per via della linea a sinistra e del
colore grigio del font).


Ciao.
Marco.
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/dcf4cdf5/attachment.html>
unknown
2013-07-12 07:22:09 UTC
Permalink
Post by unknown
2013/7/12 Daniele Varrazzo <piro a develer.com>
Post by unknown
al flame non partecipo, mi sembra piuttosto gratuito.
E fai bene.
Però ci penso io a farti partecipare citando una tua slide :-)
"People moves from PHP to Python looking for a more sane environment pretty
much as MySQL people start using Postgres when they grow up."
Non è che non sia d'accordo. Ma ho un contesto, non è un rant from
nothing. :-)
Post by unknown
Volevo solo segnalarvi che giusto domani ho un talk al PGDay UK su Psycopg.
Post by unknown
No, non chiedo se ci siete, immagino sia tardino :) Ma tra gli argomenti
che tocco c'è giusto come integrare queste nuove feature in Python (json,
hstore...) È solo una sorvolata sugli argomenti: tutti i dettagli sono nel
manuale. Ma se uno non sa che una feature esiste non se la cerca nel
manuale, giusto?
Lo slideshow è già online su <https://github.com/dvarrazzo/**
psycopg-pgdayuk-2013
<https://github.com/dvarrazzo/psycopg-pgdayuk-2013>>.
Contiene anche una demo che considero gustosa: come inviare segnali
asincroni dal database direttamente ai browser web (ed essendo lo slideshow
in html, la demo effettua un push direttamente da psql allo
slideshow :).
Beh, anche lo slideshow è interessante in sè, visto che è scritto in
reST... Insomma, se volete date pure un'occhiata: c'è più di uno spunto
(sia riguardo Postgres che altro).
Come sempre, grazie mille. Interessantissime.
Tre note veloci da nitpicker :-)
1) Il suggerimento che hai dato per diagnosticare gli idle a me non
pippo=> select * from pg_stat_activity where current_query ~ '<IDLE> in';
ERROR: column "current_query" does not exist
LINE 1: select * from pg_stat_activity where current_query ~
'<IDLE>...
Dove toppo?
Forse hai PG 9.2, dove la tabella ha cambiato schema. So che la nuova è
più facile da leggere, ma non so i dettagli.
Post by unknown
2) Nella slide dove citi Little Bobby Tables mi sa che hai scritto "second"
ma intendevi "first" nel commento finale.
cur.execute("select * from blah where key = '" + key + "'") #
BADcur.execute("select * from blah where key = %s", [key])) # GOOD
What to do if your developer writes code in the *second* style? Don't shout
at him, don't break his heart: he has only one. Break him a bone: he's got
206.
Questa penso non la sparo, verrebbe forzata :-) ovviamente sì, è
l'altro punto.
Post by unknown
3) Infine nella slide sul typecasting mi sa che hai lasciato
indentato a
destra le presenter notes (o così pare per via della linea a sinistra e del
colore grigio del font).
Ci guardo, ma le note le sto ignorando. Molte saranno finite anche al
posto sbagliato, manipolando le slide. Quelle sono il primo stream of
conciousness che stavo buttando giù (alla seconda pinta in un pub, tra
l'altro). Poi le ho trasformate in slide, perché speravo di trasformarle
in handour. Ma lo script non lo fa, e a questo giro non avevo tempo di
fixarlo, magari la prossima volta.

Ciao, grazie!
--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
unknown
2013-07-12 07:32:19 UTC
Permalink
ho un contesto, non è un rant from nothing. :-)
Non lo è, infatti.
--
Nicola Larosa - http://www.tekNico.net/
unknown
2013-07-12 07:32:53 UTC
Permalink
2013/7/12 Daniele Varrazzo <piro a develer.com>
Post by unknown
Forse hai PG 9.2, dove la tabella ha cambiato schema. So che la nuova è
più facile da leggere, ma non so i dettagli.
Sì, 9.2.4.

pippo=> \d pg_stat_activity
View "pg_catalog.pg_stat_activity"
Column | Type | Modifiers
------------------+--------------------------+-----------
datid | oid |
datname | name |
pid | integer |
usesysid | oid |
usename | name |
application_name | text |
client_addr | inet |
client_hostname | text |
client_port | integer |
backend_start | timestamp with time zone |
xact_start | timestamp with time zone |
query_start | timestamp with time zone |
state_change | timestamp with time zone |
waiting | boolean |
state | text |
query | text |

Devo leggere state o query?

Ciao.
Marco.
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/b2d5cc58/attachment-0001.html>
unknown
2013-07-12 07:42:19 UTC
Permalink
2013/7/12 Marco Beri <marcoberi a gmail.com>
Post by unknown
Però ci penso io a farti partecipare citando una tua slide :-)
"People moves from PHP to Python looking for a more sane environment
pretty much as MySQL people start using Postgres when they grow up."
+1

Ho gai detto che e' un piccole genio Daniele? Ah si, nella mail precedente
;)

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/56cf8aa0/attachment.html>
unknown
2013-07-12 07:41:21 UTC
Permalink
2013/7/12 Daniele Varrazzo <piro a develer.com>
Post by unknown
Lo slideshow è già online su <https://github.com/dvarrazzo/**
psycopg-pgdayuk-2013 <https://github.com/dvarrazzo/psycopg-pgdayuk-2013>>.
Contiene anche una demo che considero gustosa: come inviare segnali
asincroni dal database direttamente ai browser web (ed essendo lo slideshow
in html, la demo effettua un push direttamente da psql allo slideshow :).
Beh, anche lo slideshow è interessante in sè, visto che è scritto in
reST... Insomma, se volete date pure un'occhiata: c'è più di uno spunto
(sia riguardo Postgres che altro).
Sticazzi Daniele, ma tu sei un piccolo genio. It's wonderful!

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/b39177cb/attachment.html>
unknown
2013-07-12 03:30:44 UTC
Permalink
A questo punto vogliamo qualche gustoso aneddoto!!!
Ciao
diego
unknown
2013-07-12 09:15:20 UTC
Permalink
Post by unknown
2013/7/11 Enrico Bianchi <enrico.bianchi a ymail.com>
Post by unknown
Qua ti posso rispondere io. Query complessa con un fottiliardo di inner
join del tipo "WHERE t1.campo = t2.campo" in mezzo, non modificabile
perche` generata da un simil orm. Su MySQL (5.1 se non ricordo male, ma e`
un problema anche in 5.5), su macchina virutale pompata linux 64bit, il
database ci metteva un'ora per tirare fuori i dati. Su Oracle 11g, su
macchina fisica pompata linux 64bit, ci metteva 5 minuti. Su PostgreSQL
(una 9.0 o una 9.1, non ricordo), su macchina virutale windows (2003 32bit,
1 core e 512Mb di RAM allocati) ci ha messo 7 minuti
Come benchmark non male. E dimostra come non stiamo dicendo cazzate.
Carlos
--
Ah be, se questo è il tenore della discussione, neanche mi ci metto a
documentare le mie affermazioni.
Avete ragione: Postgres lo usano i professionisti, Mysql i wannabe:
quelli di *google* sono tutti dei pirla,
quelli di *facebook* e *twitter* poi non ne parliamo. *VMware* ? dei
perditempo.
*AT&T* poi, lo fanno solo per questioni di legacy. *Cisco*? bleah.
*Ericsson*? devono andare a raccogliere il basilico.
*Nokia*? sono 4 gatti, chi se ne frega. *Lufthansa*? mai sentiti.
*Paypal*? ma va là, non capiscono niente. Come quelli di
*Yahoo*! ah,*Youtube* poi, gestisce 4 video messi in croce...

ce ne sono altre centinaia di sfigati, ma chi se ne frega, quelli in
gamba sono su questa lista.

click.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/1c1df213/attachment.html>
unknown
2013-07-12 10:05:41 UTC
Permalink
2013/7/12 Alberto De Prezzo <albertodeprezzo a gmail.com>
ce ne sono altre centinaia di sfigati, ma chi se ne frega, quelli in gamba
sono su questa lista.
click.
In Abruzzo questo comportamento viene definito "ANDARE IN CASCETTA" che non
e' traducibile ma rende l'idea.

In pratica quando uno vuole ad ogni costo avere ragione e qundi fa una
affermazione STRILLATA e poi chiude per avere l'ultima parola.
Sara' che io sono convinto che se si dialoga e ci si confronta ... se io ho
un panino e tu hai un panino e ce li scambiamo, avremo sempre un panino a
testa. Se io ho una conoscenza e tu hai una conoscenza diversa e ce le
scambiamo, avremo due conoscenze a testa.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/c224dfa6/attachment.html>
unknown
2013-07-12 13:42:01 UTC
Permalink
2013/7/12 Alberto De Prezzo <albertodeprezzo a gmail.com>
Post by unknown
click.
Si dice "plonk".

*plonk*
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/250455c2/attachment.html>
unknown
2013-07-12 16:16:35 UTC
Permalink
Post by unknown
2013/7/12 Alberto De Prezzo <albertodeprezzo a gmail.com
<mailto:albertodeprezzo a gmail.com>>
click.
Si dice "plonk".
*plonk*
ROTFLASTC!**
unknown
2013-07-12 18:17:55 UTC
Permalink
Post by unknown
Ah be, se questo è il tenore della discussione, neanche mi ci metto a
documentare le mie affermazioni.
No, per favore, documenta! Da come l'avevi messa nei post prima
sembrava molto banale, quindi sono sicuro che con poco sforzo puoi
mostrare questi use-case in cui MySQL e' piu' appropriato di Postgres.
Post by unknown
Avete ragione: Postgres lo usano i professionisti, Mysql i wannabe: quelli
di google sono tutti dei pirla,
quelli di facebook e twitter poi non ne parliamo. VMware ? dei perditempo.
AT&T poi, lo fanno solo per questioni di legacy. Cisco? bleah. Ericsson?
devono andare a raccogliere il basilico.
Nokia? sono 4 gatti, chi se ne frega. Lufthansa? mai sentiti. Paypal? ma va
là, non capiscono niente. Come quelli di
Yahoo! ah, Youtube poi, gestisce 4 video messi in croce...
Vedo qualche red herring all'orizzonte:
* Argumentum ad populum
* Appeal to accomplishment (su terzi)

Se non ti va di discutere ok, ma il fatto che Brian May abbia suonato
alcuni dei piu' bei pezzi rock con una chitarra fatta in casa con una
mensola del caminetto non vuole dire che sia una buona idea suonare
tutti quanti con chitarre fatte con pezzi di caminetto...
Post by unknown
ce ne sono altre centinaia di sfigati, ma chi se ne frega, quelli in gamba
sono su questa lista.
Beh, che dire... di in gamba su questa lista ce ne sono parecchi si...

--
.
..: -enrico-
unknown
2013-07-12 18:46:24 UTC
Permalink
2013/7/12 enrico franchi <enrico.franchi a gmail.com>
Post by unknown
No, per favore, documenta! Da come l'avevi messa nei post prima
sembrava molto banale, quindi sono sicuro che con poco sforzo puoi
mostrare questi use-case in cui MySQL e' piu' appropriato di Postgres.
Su un progetto in cui sono subentrato si doveva scegliere tra M$SQL e MySQL
(erano gli unici supportati dal framework che stiamo usando).
Alla fine hanno scelto MySQL e non so bene perché.
Io ero contento della scelta perché almeno si poteva rimanere su Open
Source e Linux.

Adesso dopo aver sentito tanti pareri schifati di MySQL non so più cosa
pensare.

Chiedo a voi detrattori di MySQL: un MySQL su Linux é anche peggio di un
M$SQL su Windows?

Ciao
--
Andrea Francia http://andreafrancia.it
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/1de32fdb/attachment.html>
unknown
2013-07-12 19:15:54 UTC
Permalink
2013/7/12 Andrea Francia <andrea a andreafrancia.it>
Post by unknown
Su un progetto in cui sono subentrato si doveva scegliere tra M$SQL e
MySQL (erano gli unici supportati dal framework che stiamo usando).
Per mia curiosita' ma di quale framework si tratta? no, cosi', solo per
evitarlo come la peste. ;)

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/419a4396/attachment-0001.html>
unknown
2013-07-12 19:28:25 UTC
Permalink
2013/7/12 Carlos Catucci <carlos.catucci a gmail.com>
Post by unknown
Per mia curiosita' ma di quale framework si tratta? no, cosi', solo per
evitarlo come la peste. ;)
Preferisco non dire come si chiama. Dico solo che se rimani su Python non
ti capiterà mai di usarlo.

Ciao
--
Andrea Francia http://andreafrancia.it
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/670e139c/attachment.html>
unknown
2013-07-12 19:30:09 UTC
Permalink
2013/7/12 Andrea Francia <andrea a andreafrancia.it>
Post by unknown
2013/7/12 Carlos Catucci <carlos.catucci a gmail.com>
Post by unknown
Per mia curiosita' ma di quale framework si tratta? no, cosi', solo per
evitarlo come la peste. ;)
Preferisco non dire come si chiama. Dico solo che se rimani su Python non
ti capiterà mai di usarlo.
Drupal?
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/53b8d4b0/attachment.html>
unknown
2013-07-12 19:38:46 UTC
Permalink
2013/7/12 Marco Beri <marcoberi a gmail.com>
Post by unknown
Preferisco non dire come si chiama. Dico solo che se rimani su Python non
Post by unknown
ti capiterà mai di usarlo.
Drupal?
Peggio!

Ciao
--
Andrea Francia http://andreafrancia.it
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/2459da68/attachment.html>
unknown
2013-07-12 19:41:52 UTC
Permalink
2013/7/12 Marco Beri <marcoberi a gmail.com <javascript:_e({}, 'cvml',
'marcoberi a gmail.com');>>
Post by unknown
Preferisco non dire come si chiama. Dico solo che se rimani su Python non
Post by unknown
ti capiterà mai di usarlo.
Drupal?
Peggio!
un porting di Drupal in C#? ( la prima cosa "peggio" che mi è venuta in
mente dopo ASP.NET)...
--
Valerio
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/185b62a9/attachment.html>
unknown
2013-07-12 19:41:17 UTC
Permalink
2013/7/12 Andrea Francia <andrea a andreafrancia.it>
Post by unknown
2013/7/12 Marco Beri <marcoberi a gmail.com>
Post by unknown
Preferisco non dire come si chiama. Dico solo che se rimani su Python non
Post by unknown
ti capiterà mai di usarlo.
Drupal?
Peggio!
È in questa lista?

http://www.phpframeworks.com/
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/87e49ab8/attachment-0001.html>
unknown
2013-07-12 19:51:59 UTC
Permalink
2013/7/12 Marco Beri <marcoberi a gmail.com>
Post by unknown
È in questa lista?
http://www.phpframeworks.com/
Peggio: é scritto in Java.

Ciao
--
Andrea Francia http://andreafrancia.it
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/df5f755d/attachment.html>
unknown
2013-07-12 20:15:11 UTC
Permalink
2013/7/12 Andrea Francia <andrea a andreafrancia.it>
Post by unknown
Peggio: é scritto in Java.
AAAArrrrrggggghhhhhh!!!!!!
Usi java (linguaggio pedante e pesante ma pur sempre multipiattaforma) e
poi lo castri sul DB?

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/ba034a35/attachment.html>
unknown
2013-07-12 20:17:53 UTC
Permalink
2013/7/12 Marco Beri <marcoberi a gmail.com>
Post by unknown
È in questa lista?
http://www.phpframeworks.com/
Li in mezzo il meno peggio (che come dico "sempre peggio rimane") per me e'
Symfony.
Un ORM decente, un sistema di templating non del tutto idiota, YAML per i
config (certo avrei preferito json ma YAML e' piu' leggibile), multiDb e
multipiattaforma, con le sandbox hai un progetto potrabile AS IS tutto in
una cartella da deployare (quindi ache su host osceni come aruba).

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/7e96a3f4/attachment-0001.html>
unknown
2013-07-12 20:13:20 UTC
Permalink
2013/7/12 Marco Beri <marcoberi a gmail.com>
Post by unknown
Drupal?
Non e' un framework e' un CMS. Ed e' di certo meno peggio di Joomla.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/d26b3f52/attachment.html>
unknown
2013-07-12 20:12:24 UTC
Permalink
2013/7/12 Andrea Francia <andrea a andreafrancia.it>
Post by unknown
Preferisco non dire come si chiama. Dico solo che se rimani su Python non
ti capiterà mai di usarlo.
Se posso io altri linguaggi web li evito. In particolare il Probably
Harmfull Programming. ;)

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/061a6ad1/attachment.html>
unknown
2013-07-12 19:18:09 UTC
Permalink
2013/7/12 Andrea Francia <andrea a andreafrancia.it>
Post by unknown
Chiedo a voi detrattori di MySQL: un MySQL su Linux é anche peggio di un
M$SQL su Windows?
Da mie esperienze posso solo dire che eviterei entrambi potendo. Pero' side
effect quali float arrotondati (100.00 che diventa 99.9999999999) su
MsSqlServer, con tutto il male che gli voglio, e non e' poco, non ne ho mai
visti. Che poi IMHO sia una porcata di db anche lui e' altro discorso.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/b9257664/attachment.html>
unknown
2013-07-12 19:38:10 UTC
Permalink
2013/7/12 Carlos Catucci <carlos.catucci a gmail.com>
Post by unknown
Che poi IMHO sia una porcata di db anche lui e' altro discorso.
OK, grazie della risposta.
Però c'e' una cosa che non capisco:
Mi avete detto che MySQL fa schifo e mi sembrate convincenti
Mi dici che SQL Server è brutto e non faccio fatica a crederci
Mi dite che Postgres va bene e me l'hanno detto in tanti

Però non ho capito le opinioni che avete su Oracle DB. Io mi ricordo che
(nel 2004) era una schifezza, che ci volevano 3 giorni per installarlo su
una RedHat (su Windows molto meno), che aveva bisogno di mille dipendenze,
che era ed é closed source e che comprare una licenza Oracle voleva dire
doversi poi comprare anche i consulenti Oracle per far funzionare le cose.
Poi non l'ho più usato e non l'ho neanche mai stressato.

Da quello che mi é parso di leggere non c'erano commenti schifati su Oracle
DB. Ma quindi é meno peggio di MySQL?

Scusate se vi faccio fare la classifica anche dei meno peggio :-)

Ciao
--
Andrea Francia http://andreafrancia.it
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/862942b4/attachment.html>
unknown
2013-07-12 15:54:03 UTC
Permalink
Post by unknown
Si dice "plonk".
*plonk*
DNFT
/
click.
/
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130712/4220f428/attachment.html>
Continue reading on narkive:
Loading...