Newsgroup: it.comp.os.dibattiti
Titolo: Sun compra MySQL

http://developers.slashdot.org/article.pl?sid=08/01/16/135243&from=rss
Nonostante le mie considerazioni (che, normalmente, non tengo nascosto) su
MySQL, devo dire che Sun ha fatto un colpo grosso quanto un palazzo.
Personalmente pero` incomincio anche ad avere un po' di paura di Sun: se
non fosse per il fatto che il suo parco software e` costituito per lo piu`
da software open source (o che implementa standard aperti e consolidati),
mi sembra di trovarmi di fronte ad una piccola Microsoft
Enricoo

Enrico 'Henryx' Bianchi wrote:
:: 
http://developers.slashdot.org/article.pl?sid=08/01/16/135243&from=rss

Io direbbi che sei di fronte proprio a Microsoft :-)

 Io direbbi che sei di fronte proprio a Microsoft :-)
Sei perfido :)
Enrico

 MySQL, devo dire che Sun ha fatto un colpo grosso quanto un palazzo.
non sono convinto: mi spiego: sbaglio o la tecnologia di innodb (e pure 
la ditta che la sviluppa) è stata comprata da oracle? A cose serve 
possedere mysql senza l'integrità referenziale?

 possedere mysql senza l'integrità referenziale?
Sì ma da tempo, e tuttavia con diritto di utilizzarlo in MySQL (infatti
l'autore di InnoDB e collaboratori vari sono ancora più che attivi nel
bugzilla pubblico di Mysql). in ogni caso Mysql ha già in sviluppo da oltre
un anno un altro motore che dovrebbe sostituire in un futuro a InnoDB:
Falcon (credo che il piano è che sia il default in Mysql 6).
-- 
Vide

Ottavio Campana ha scritto:

Mysql 5.x ha un sistema a plugin di storage , il che vuol dire che
non e' difficile sostituire innodb con altro.

 Io direbbi che sei di fronte proprio a Microsoft :-)
E' l'anno di SOLARIS !!!
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://www.flatpress.org

Vide ha scritto:

falcon? questo?
http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/
ok, il post è vecchio, spero che migliorino molto...

 non e' difficile sostituire innodb con altro.
Che altro?
-- 
Valentino Volonghi aka Dialtone
http://stacktrace.it
 -- Aperiodico di resistenza informatica
Blog: 
http://www.twisted.it/
http://iccfriends.net/friend/Dialtone

 
Leggi sopra.

 smentirlo...
Piu` che le dimensioni parlavo dell'offerta software. Praticamente Sun
potrebbe diventare la Microsoft per il mondo aziendale
Enrico

 wrote:

Che altro?


Enrico 'Henryx' Bianchi ha scritto:

la ms dei prodti aziendali ci sono gia, una si chiama IBM, e l'altra si 
chiama oracle, entrambe hanno so, db, application serve, tool x 
sviluppatori, ibm ha ancha il ferro se serve
cmq la cos ache mi chiedo è come mai hanno comprato mysql quando sono 
tra i i principali supporter di postgresql,
fors evogliono entrare nel mercato lamp, ma allora perche non comprarsi 
la zend?
mah my 2c

Enrico 'Henryx' Bianchi ha scritto:

Perche' Microsoft nel mondo aziendale non ha mercato ?

 la zend?
Perchè Mysql è molto più trasversale. Lo usa gente che scrive in java, in
python, in ruby, in 
asp.net
 e, ovviamente, in PHP.
-- 
Vide

 python, in ruby, in 
asp.net
 e, ovviamente, in PHP.
Se ciao... E` una delle prerogative di SQL non di mysql.


 Se ciao... E` una delle prerogative di SQL non di mysql.
Sto parlando di implementazioni reali, non che ogni linguaggio può
connettersi a differenti DBMS (che mi pare un'ovvietà).
-- 
Vide

 connettersi a differenti DBMS (che mi pare un'ovvietà).
Tutti i linguaggi che hai citato hanno librerie stabili e diffuse per
connettersi a postgresql.
Non solo... In almeno 3 di quelli e` possibile scrivere stored
procedures dentro postgresql.
Le ragioni per cui mysql e` usato non hanno nulla a che fare con la
tecnica o le librerie disponibili. Sono di tutt'altro genere, piu`
politico.


 mi sembra di trovarmi di fronte ad una piccola Microsoft
"So, what's the theme? You can make some money with FOSS. Period."
Groklaw - Details on the Sun-MySQL Deal
http://www.groklaw.net/article.php?story=20080116110733421
-- 
http://ppg-anfscd.blogspot.com/

 
http://www.groklaw.net/article.php?story=20080116110733421
In effetti vendere licenze e' sempre stato il business model perfetto del 
FOSS.
  ngw
-- 
"ma gavte la nata." -- Jacopo Belbo
http://www.tochunky.org

 Perchè Mysql è molto più trasversale.
Trasversale nel senso che uno se lo infila in culo di traverso o cosa?
Nel senso che raramente ho trovato un dbms più cessoso, eh. Poi per
tenerci su il blog e il forum va pure bene: ma diciamola, sono compiti
che in se e per se *non* hanno quasi bisogno di un dbms.
Tanto è vero che SQLite funziona eccellentemente in tali ambiti.
-- 
cc = callcc {|cc| cc.call cc}; cc.call cc

 Nel senso che raramente ho trovato un dbms più cessoso, eh. Poi per
Concordo, ma SUN punta anche a vendere macchine per far da server web,
in proposito qualche tempo fa in un suo post Jonathan esaltava il fatto
che Niagara consuma una frazione dei processori x86, anche perché non ha
una FPU potentissima, ma aggiungeva che proprio per questo va benissimo
nei datacenter dove si fa solo web, e tutti sappiamo che le offerte per
domini web sono tipicamente LAMP, dove M = MySQL...
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

 LAMP, dove M = MySQL...
Io ero sempre stato convinto che stesse per un'altra cosa, in
particolare un attributo di PHP...


 particolare un attributo di PHP...
Machemerdadilinguaggio? 8-)


 MySQL, devo dire che Sun ha fatto un colpo grosso quanto un palazzo.
Oracle ha "risposto" comprando BEA, che è tra i leader per quel che
riguarda gli application server J2EE:
http://it.slashdot.org/article.pl?sid=08/01/16/1754227&from=rss
Raffaele

 Machemerdadilinguaggio? 8-)
Diciamo che quello che intendevo io inteso come regexp (case
insensitive) matcha la tua stringa.


 Oracle ha "risposto" comprando BEA, che è tra i leader per quel che
e Oracle possedeva già da tempo InnoDB.


 insensitive) matcha la tua stringa.
s/^Mache(.*)dilinguaggio$/$1/gi; ? 8-)
Si vede che è un sabato sera passato a lavorare? 


 Si vede che è un sabato sera passato a lavorare? 
eh, veramente io intendevo il contrario. In particolare la parola da me
suggerita matcha la tua stringa (oltre che se stessa...) :P


 me suggerita matcha la tua stringa (oltre che se stessa...) :P
scusa ma non ho capito, me la spieghi?
Grazie, Micky


 che in se e per se *non* hanno quasi bisogno di un dbms.
Blog o forum come Google? o come Facebook? o come migliaia di altri siti 
più complessi di quello che dici? Sparlare di Mysql è ormai una moda fra 
i geek. Le mie idee sul perchè ce le ho, se volete ve le (ri)spiego :P

 politico.
Le ragioni per cui Mysql è più diffuso è esattamente la stessa per cui 
Linux è più diffuso sui server di FreeBSD e per cui Windows è più 
diffuso sui desktop di Linux. Perchè sono più semplici da cominciare a 
utilizzare per il principiante, e funzionano abbastanza bene per quello 
che devono fare.
Il resto sono seghe mentali.

):

Saranno seghe mentali, ma personalmente un tecnico che mi fa un discorso di 
questo tipo riceve l'atzeni gratis e 1 mese di ferie non pagate :)
A parte le cagate, la semplicita' conta decisamente poco (semplicita' dove, 
tra l'altro ? Puoi fare del merdoso CRUD anche con Oracle), il tuo discorso 
e' incredibilmente semplicistico e poco adatto all'ambito in cui operiamo.
MySQL viene usato perche' ci sono piu' tecnici che lo conoscono, ha un 
backend di support e licensing a livello societario (il che lo rende 
OpenSource come il culo di Ballmer, per me),  e perche' a botte di hype e' 
riuscito a far passare informazioni spesso semplicemente false.
I motivi per parlarne male ci sono (e io lo sto sperimentando sulla mia 
pelle, visto che mi ritrovo ad usare la loro merdosa soluzione per il 
Clustering, dove sicuramente societa' come google hanno le palle per 
svilupparsene una loro), per non entrare nel merito del puttanaio che hanno 
creato con i backend, unico dbms al mondo ad avere il featureset definito in 
base a cosa usi per tenere le tabelle.
Poi se a te piace cavoli tuoi, se posso avere di meglio (cisto che non ho la 
"richiesta di semplicita'" nel contratto, dovrei essere un tecnico) lo 
prendo.


 i geek. Le mie idee sul perchè ce le ho, se volete ve le (ri)spiego :P
Mah, io di MySQL parlo male da parecchio tempo, non è mai stata una
moda. Semmai spiegami perchè MySQL dovrebbe essere figo. Permettimi di
non trovare particolarmente interessante quello che tu pensi sul perchè
a me non piace MySQL. 


 scusa ma non ho capito, me la spieghi?
In un'espressione regolare i caratteri alfabetici non protetti matchano
se stessi. Da cui 'merda' matcha 'merda'. E matcha pure
'machemerdadilinguaggio' o quello che era :)


 'machemerdadilinguaggio' o quello che era :)
Fin lì ci arrivo da solo, volevo solo sapere a cosa corrisponde la M di
LAMP per te, ma mi sa che corrisponde a Merda...
Ciao, Micky


 prendo.
Non è che sia il più grande ammiratore di Mysql, anzi come già detto fa 
girare le scatole anche a me (e pure molto, alle volte), semplicemente 
non vedo di buon'occhio la gente che attacca per partito preso.

 Semmai spiegami perchè MySQL dovrebbe essere figo. 
Non ho mai detto che sia "figo". Ho detto che è semplice, quindi lo può 
usare tanta gente e quello per cui è stato pensato lo fa decentemente.

 non vedo di buon'occhio la gente che attacca per partito preso.
Partito preso? Non hai bisogno che ti si elenchino tutti i problemi di
mysql vero? A me sembra che sia tu che lo difendi per partito preso
piuttosto, cercando anche di spargere fud nel contempo.


 usare tanta gente e quello per cui è stato pensato lo fa decentemente.
Quello che dici e` falso e lo continui a dire nonostante tutto.


 LAMP per te, ma mi sa che corrisponde a Merda...
Quindi espando (volevo fare il raffinato, ma mi sa che mi tocca):
La merda PHP.


 usare tanta gente e quello per cui è stato pensato lo fa decentemente.
Stai parlando di Firebird o di SQLite? No, perche` installare ed
_amministrare_ MySQL e` tutto fuorche` semplice...
Enrico

 questo ne ha decretato il successo.
La fortuna di MySQL si e` creata semplicemente per il fatto che, ai tempi di
MySQL 3, era il database che riusciva a processare le query il piu`
velocemente possibile[1], mentre PostgreSQL era drammaticamente lento e
Firebird stava cercando di uscire da quella fogna in cui era stato
scaricato da Borland/Inprise. Inoltre non si deve dimenticare un aneddoto
importante: PHP all'epoca aveva i driver per MySQL integrati
Enrico
[1] grazie al piffero, non dovendo gestire vincoli e transazioni...

 usare tanta gente e quello per cui è stato pensato lo fa decentemente.
Mah... questo 'semplice' io non lo vedo. Non più di PostgreSQL per dire.
Diciamo invece come stanno le cose: MySQL gira su Windows dal 1998.
PostgreSQL da un paio di anni (forse tre, forse uno, poco importa).
Per cui un sacco di sviluppatori punta e click con PHP potevano provare
a casa e buttare sul server.
A questo punto bisogna decidere *cosa* è stato pensato per fare. Tanto
per decidere se lo fa decentemente. 
Ah... presente la posizione di MySQL AB con SCO? Pensaci prima di
difenderli tanto... oppure fai meno il 'paladino' di Linux :P


 [1] grazie al piffero, non dovendo gestire vincoli e transazioni...
Esatto, ma nessuno (non io, almeno) lo ha mai negato. Era piů veloce 
perchč faceva meno. Ma le cose che faceva bastavano agli utilizzatori, 
che per un piccolo overhead non avevano da smazzarsi file di testo o 
linkarsi a sqlite.

Enrico 'Henryx' Bianchi ha scritto:

Installazione e amministrazione basica di Mysql le possono fare anche i 
bambini (insomma, ci riesco io :P). Sqlite è una libreria e quindi per 
web-application non conta, e Firebird non lo conosco, ma comunque ai 
tempi dell'esplosione di Mysql non era opensource (di quand'è il 
passaggio Interbase->Firebird?)

 difenderli tanto... oppure fai meno il 'paladino' di Linux :P
rinfrescami la memoria :P

 
http://it.slashdot.org/article.pl?sid=08/01/16/1754227&from=rss
ma questa risposta si sapeva già da qualche mese.
e comunque oracle possiede anche innodb.
-- 
Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com

 tuo utile. io lo trovo di una gravità allucinante. poi fai tu.
Questa e` quella corretta. All'epoca in cui introdussero il supporto alle
foreign key ti trovavi elogi dappertutto su questa meravigliosa
funzionalita`, e le frasi discriminatorie sparirono magicamente nel nulla.
Ma la cosa grottesca e` che la gente ci credeva! Una volta mi sono
ritrovato a dover discutere con un tizio che riteneva i trigger, le stored
procedure e le viste qualcosa di assolutamente inutile, messe li come pezza
alla deficienza di alcuni sviluppatori
Enrico

 passaggio Interbase->Firebird?)
Amministrare un DB non _deve_ essere una cosa da bambini
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 (di quand'è il passaggio Interbase->Firebird?)
Interbase 6 e` stato rilasciato open source nel 2000
Enrico

 Sparlare di Mysql è ormai una moda fra i geek
The blogosphere agrees: dweebs/geeks/nerds are idiots.
///
MySQL Customers by Industry:
http://www.mysql.com/customers/
-- 
http://ppg-anfscd.blogspot.com/

 rinfrescami la memoria :P
Mah, avevano accordi piuttosto stretti e non hanno mai preso posizione
contro SCO nel caso contro Linux. 


 Amministrare un DB non _deve_ essere una cosa da bambini
Quoto. Ma soprattutto... il sistema operativo deve costringerti ad
imparare anche se vendi prosciutti e il DB deve potere essere
amministrato da un bambino?
Credo di avere un errore nella transizione di stato.


 passaggio Interbase->Firebird?)
No, non credo lo fosse. Eppure è ottimo. Io continuo a preferire
Postgres, ma è una questione di *gusti*.


 alla deficienza di alcuni sviluppatori
Appunto. Questo è un comportamento IMHO criminale. 


 
http://www.mysql.com/customers/
Ne riparliamo il 31 febbraio <g>.


 massimo può cambiare qualche dettaglio con un'opzione a runtime.
quanti altri dabatase hanno backend diversi?

Enrico 'Henryx' Bianchi ha scritto:

vero, mysql nelle querey con una singola insert/delete/update è più 
veloce di postgresql per una serie di motivi, tra cui anche la sua 
gestione delle tuple.
Il fatto è che molte applicazioni lamp fanno proprio questo tipo di 
operazioni e non fanno uso di integrità referenziale. quindi mysql 
faceva poco, ma era quel poco che in molti cercavano.

 linkarsi a sqlite.
sqlite? ma manco quello è ACID... non ha manco la tipizzazione...
PS: ok, vero che coi trigger puoi ottenere una simil-integrità 
referenziale, però....

 accedono piů applicazioni, ma č parte stessa dell'applicazione). 
il fatto di spostare la logica nell'applicazione imho č raccapricciante.

 Amministrare un DB non deve essere una cosa da bambini
E neanche un sistema se per questo, eppure è pieno di Windows amministrati a
colpi di click e di LAMP amministrati colpi di webmin. Ripeto, scazza (e
scazza anche a me, visto che sono un tecnico), lo so benissimo, ma questo
non significa non prendere atto che la realtà sia così e i prodotti più di
successo sono quelli apparentemente più facili da utilizzare.
-- 
Vide

 abbia anche successo.
le FK non servono se fai programmini come un blogghetto o il ricettario 
web di nonna Amelia.
Ma per le applicazioni serie serve eccome.

 quanti altri dabatase hanno backend diversi?
Nessun'altro, AFAIK :)
-- 
Vide

 successo sono quelli apparentemente più facili da utilizzare.
Che poi, lo dico per tutti visto che mi sono un po' stufato di rispondere a
mille persone :P, è questo il succo del mio discorso. Non sto difendendo la
bontà di Mysql, sto solo cercando di farvi capire i motivi che secondo me
l'han portato al successo:
- multipiattaforma
- velocità
- semplicità
che hanno avuto più importanza di tutti i grossi difetti che Mysql *ha*.
EOD
-- 
Vide

 il fatto di spostare la logica nell'applicazione imho è raccapricciante.
Spostarla dove? Ci sono quelli che no alle stored procedure, tutto
sopra, quelli che tutto sotto e vattelapesca; quale delle due è
raccapricciante? :)
Io personalmente sono pragmatico: se stai scrivendo un'applicazione che
ha accesso esclusivo ad un db (e per come è pensato il sistema tale
accesso *rimane* esclusivo nei tempi dei tempi), il fatto che quello sia
proprio un db piuttosto che un altro sistema di storage può anche essere
un dettaglio, se viene più comodo. 
In particolare delle famose ACID viene a cadere sicuramente l'isolamento
(nel senso che non interessa, visto che ci sono solo io). La consistenza
può in effetti essere implementata a livello applicativo (ancora una
volta, chiaramente la cosa è subottimale, ma 
uno potrebbe stare usando sqlite più per ragioni di efficienza/mancata
voglia di scriversi un formato di salvataggio che perchè è una specie di
database[0]). L'atomicità è gradevole a prescindere e idem la
durabilità.
Nota che io non sto dicendo che sia cosa buona e giusta. Mi limito a
dire che in questo contesto il tutto assume un differente peso. In
particolare, ribadisco, il fatto che sotto ci sia un DB ed SQL è quasi
uno sfizio di comodità. 
-----
[0] poi a me viene male a scrivermi il codice per gestirmi le fkey a
mano, eh. meno male che con sqlite lo puoi far fare a dei trigger, che
anche se non particolarmente efficienti e comodi sono comunque
relativamente trasparenti, una volta scritti.


 web di nonna Amelia.
Sul ricettario ok. Anche sul blog vedo seri problemi, io.  
Specie quando si usano ID numerici. Da cui il post appartiene alla
categoria '5' che č stata cancellata. Che succede? Io voto che scoppia
una qualche eccezione e non si legge piů un accidenti.


 relativamente trasparenti, una volta scritti.
concordo

 gestione delle tuple.
Penso tu abbia letto il mio post su iclpy, te lo riporto comunque qua:
http://www.postgresql.org/docs/techdocs.83
http://tweakers.net/reviews/657/1/database-test-dual-intel-xeon-5160-pag
ina-1.html
Non mi sembra molto veloce.


 Sul ricettario ok. Anche sul blog vedo seri problemi, io.  
sě sě, ok, ma ho detto blog per dare l'esempio di una applicazione che 
se non va non muore nessuno o non si perdono soldi.

 Non mi sembra molto veloce.
beh, perņ, aspetta, io mi riferivo alla sua gestione delle tuple. in 
postgresql afaik quando fai un delete le tuple non vengono cancellate 
fino a quando non fai un vacuum e questo lo puņ rallentare.

 di logica, che è più vicina a chi fa il db.
Beh, ma cosa centra. Non c'è mica scritto da nessuna parte che chi fa la
logica di interfaccia debba fare la logica business o la gestione dei
dati. Tipicamente chi scrive la parte che mappa il modello relazionale
nel modello ad oggetti dell'applicazione farà in modo che usando la
'libreria' scritta non sia possibile violare l'integrità referenziale
etc. 
Ad ogni modo io sono per il 'fail early'. I controlli farli quando
possibile a più livelli, prendere gli errori il prima possibile etc. 
Ribadisco, mica sto dicendo che bisogna ficcare tutto nell'applicazione.
Tuttavia ci sono fior di esempi nel mondo reale in cui effettivamente
fare le cose a livello applicativo non è un dramma. Tipicamente quando
il tutto è su un solo livello. 


 Altri blog anche in PHP son fatti meno a capa di cazzo.
Mah. Tipo?


 se non va non muore nessuno o non si perdono soldi.
Si, certo. :)


 indicibile perchè è improbabile da espandere.
io ho smesso di usare quando mi sono reso conto di cosa stavo 
producendo.....

 io sono per ficcare la logica il più possibile nel db.
Spero non tutta infilita nelle SP ;-)
Io sono dell'idea che il DB debba garantire l'integrità di dati,
l'accesso concorrente ecc ecc.
La logica applicativa deve stare nel model dell'applicazione.
Non c'è niente di peggio che dover andare a editare SQL perché qualche
pirla ha infilato la conversione delle date da e verso applicazione in
una SP :D
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 possibile a più livelli, prendere gli errori il prima possibile etc. 
Esatto, io a volte sono maniacale, però secondo me il DB deve essere il
failsafe. È scemo fargli fare un inserimento di qualcosa che 14 livelli
prima so essere invalido.
Tipo: ho una colonna con NOT NULL.
Che ci vuole a controllare che quel valore esista (e che magari arriva
da una form web) prima di tentare l'INSERT o l'UPDATE?
Un conto è la gestione delle foreign keys, un conto è sapere se un campo
è nullo.


 - semplicità
Ma su questo son d'accordo. Dimentichi: posto giusto al momento giusto e
macchina di marketing.


 Windows idem. Su Linux hai comunque apt-get.
Personalmente nell'installazione di Postgres su Windows ho smadonnato un
paio di calendari, soprattutto perche` mi ostinavo a farla da remoto mentre
l'installer voleva partire da macchina locale :D
Enrico

 producendo.....
Io fortunatamente non ho manco iniziato veramente con PHP. Ho avuto la
fortuna di dovere mettere le mani nell'altrui codice e la semplice
esperienza traumatica mi ha dissuaso da procedere. Purtroppo di tanto in
tanto mi capita ancora come favore ad amici. Ma devono essere belle
grosse le birre che mi offrono.


 l'installer voleva partire da macchina locale :D
Io ho visto dei doppioclick andare a segno. Magari sarà stata un'altra
versione. Io poi win non lo uso, per cui non conosco i dettagli. 


 prima so essere invalido.
Quoto tantissimo. 


 database[0]
Questo personalmente lo vedo come un grosso vantaggio. Tralasciando casi
particolari (e.g. un formato grafico), nella maggior parte delle
applicazioni vengono usati dei file proprietari per scrivere i dati
raccolti e/o gestiti dall'applicazione stessa. Personalmente, ritengo che
utilizzare un formato contenitore comune (quale e` SQLite) sia il modo piu`
semplice e flessibile che ci possa essere
Enrico

 versione. Io poi win non lo uso, per cui non conosco i dettagli.
Non mi sono spiegato bene. L'installer di PostgreSQL per Windows non parte
se viene lanciato da terminal client. Non ci sono cazzi, o si installa via
archivio zippato (che, a dire il vero, neanche ricordo se esiste), o si
installa accedendo direttamente alla macchina. Per fortuna la situazione e`
migliorata, il nuovo db server (un dual xeon quad core con 8Gb di RAM e 6
HD SAS da 300Gb l'uno e a 15000 giri[1]) utilizza Linux come sistema
operativo :)
Enrico
[1] si, mi sto bullando :P

 è nullo.
Quoto e straquoto.
Ed aggiungo:
Il DB pensi a tenere insieme i dati, che alla logica applicativa ci
penserà qualcun'altro.
Per quel che la mia opinione ci sono due casi in cui la logica và nel
DB:
1) hai deciso e/o sei costretto a mettere praticamente tutta la logica
nel DB (tipo con la forms di oracle)
2) hai problemi di performances, ergo usi le SP per eliminare
eventuali colli di bottiglia
Ci si potrebbe aggiungere un terzo, riguardo le elaborazioni batch ma
dipende dal tipo di operazione.
Raffaele

 dipende dal tipo di operazione.
4) preferisci usare SP perché in questo modo ti togli un middleware di 
business logic che nello sviluppo di più applicazioni che accedono alla 
stessa base di dati ti costerebbe troppa fatica mantenere.

 La logica applicativa deve stare nel model dell'applicazione.
che ne dici di un nuovo binding a GTK per plpgsql? :-P

 stessa base di dati ti costerebbe troppa fatica mantenere.
Ma non è una cosa più adatta a rientrare in una libreria? Ma
probabilmente questo è più un problema (quello di slegarsi dal DB) di
chi non ha pieni poteri riguardo la piattaforma (ecco, diciamo che le
stored procedure non sono esattamente la cosa più portabile di questo
mondo, via...)
Raffaele

 dell'applicazione.
Questo è chiaramente sbagliato, ma io vorrei discutere un altro punto
che IMHO da come scrivi non è di concordia.
Mi sembra che tu intenda come model il db (e quello che sta nel db).
Questo invece *non* è necessariamente vero. Il model è responsabile
della manipolazione dei dati 'crudi' e di presentarne una vista logica
all'applicazione (in particolare agli strati soprastanti). Il model è
*anche* responsabile della persistenza, ma *non* è il sistema di
persistenza. In model *sa* come rendere persistenti i dati, ma non è il
sistema di persistenza: ci sta *appena sopra*.
Cambiando db per dire cambi un dettaglio  implementativo del model, non
il model stesso. 


 mondo, via...)
no vero, non sono portabili. Però per fortuna io non ho il problema di 
muovermi tra un db e l'altro. Insomma, imparare ad usare bene un db per 
farci manipolazioni pesanti di dati in modo efficiente richiede un botto 
di tempo. Allora cosa mi conviene fare: ne uso uno bene o tanti male?

 il model stesso. 
sì sì, l'ho anche scritto a Raffaele.
Ma quante applicazioni *serie* avete scritto che richiedessero 
compatibilità con più di un db? Il problema non sono le querine sceme, 
le join o le viste. Il problema è far correre il db. E non tutti corrono 
allo stesso modo.
Il software del blog che è venuto fuori qualche post fa è un software 
che non deve correre e che se gira su più db è meglio. Ma con 
applicazioni più grosse mica si passano le giornate a cambiare db. :-)
E' per questo motivo che io aborro gli ORM. Mi va bene fare astrazione, 
ma proprio di tutto tutto tutto no! Preferisco definire una api di 
smandruppamento dei dati, chi sta sopra la usa nelle applicazioni, chi 
sta sotto si impegna a farla correre.

 diventa una scelta -quasi- obbligata...
Guarda: 
        •       3 sottodomini
        •       1 Giga di spazio Web con supporto PHP5, Perl, Python,
Ruby, ERuby, Tcl, Haskell, Rails, Pylons, Nevow, Bazaar, Tcl,
RubyOnRails, Django, Symfony, Ramaze, Catalyst, Mason, Turbogears,
CherryPy, Genshi, Twisted.web, Camping, Sqlite, e Nitro con FastCGI.
Gestione modalita' 'readonly' e Trusted Path Execution per gli script
web.
        •       Gestione modalita' FastCGI per gli script PHP5
        •       2 respository Subversion
        •       illimitati progetti Trac
        •       20 caselle di posta con infiniti alias accessibili via
POP3 over SSL per la massima sicurezza con gestione blacklist e filtri
antispam, antivirus e amministrazione quota
        •       Gateway mailbox2webapp per lanciare script web alla
ricezione di una mail
        •       1 Account MySQL-5/PostgreSQL-8.1 amministrabile via
interfaccia web in HTTPS (3 database)
        •       Gestore MailingList/NewsLetter (Mailman)
        •       Gestione Crontab
        •       Supporto Mercurial
        •       2 account smtp
53,00 € annui


 sta sotto si impegna a farla correre.
Beh, facciamo un pò di distinzione: gli ORM vanno benissimo per
mappare un modello su un sistema di storage. L'elaborazione deve stare
o da una parte o dall'altra, o entrambe, non certo nell'ORM.
Raffaele

 una SP :D
Facciamo esempi piu` reali.
Piu` roba sta nel db piu` sono tranquillo. D'altronde non si vede
perche` in tutti i software si cerca di mettere i vincoli il piu` in
basso possibile mentre nel db si faccia di tutto per sbattere tutto il
piu` in alto possibile. E` una cosa di cui proprio non mi capacito.
Tanto piu` che, almeno postgresql, non necessita di SQL ma puoi usare i
linguaggi che vuoi sostanzialmente.
-- 
Valentino Volonghi aka Dialtone
http://stacktrace.it
 -- Aperiodico di resistenza informatica
Blog: 
http://www.twisted.it/
http://iccfriends.net/friend/Dialtone

 scriverlo un blog, figuriamoci per crearselo da zero...
Mica quello dicevo: intendevo dire che con un hosting tipo quello scegli
il blog che ti piace senza preoccuparti che sia PHP.


 dell'applicazione.
Questo però è un problema di logica implementativa, non di dove deve
stare effettivamente la logica 
