[Primipassi] equivalente di access

[Marco Ermini]

Aldo <a.podavini@ldvsrl.it> wrote:
> Beh, me l'ero cercata :-)

Ogni tanto uno scambio di battute ;-) schiariscono le idee...


[...]
> - mysql è MOLTO veloce ad eseguire query semplici;
> - per sua natura non è proprio in grado - tout court - di eseguire query 
> complesse;
> - per ovviare a questo limite si è costretti a fargli eseguire tante 
> query semplici (al posto di poche complesse), e il tempo totale di 
> esecuzione dipende ovviamente da come è stato impostato il lavoro.
[...]

Su questo sono d'accordo con te. Questa pero', ti faccio notare, e' sempre
stata una scelta precisa, ed e' esattamente il motivo per cui MySQL viene
usato dai suoi utenti. Per cui, se lo vuoi "dipingere come un difetto", stai
commettendo, diciamo cosi', una "scorrettezza intellettuale".

Se ti interessa un DB che per molti versi si "autoregola" (nel senso che
esegue mediamente bene tanti tipi di query, anche quando e' usato magari male)
allora penso che devi andare su Oracle o DB2, ma sicuramente hai in questo
caso anche un altro "target" che MySQL non puo' raggiungere.


[...]
> Oracle no, DB2 sì.
> Condivido il tuo giudizio. Ma ammetterai che per uno che parta 
> dall'ambito di Access (che mi pare fosse il contesto della richiesta 
> originaria) ...

In questo caso, quando installi MySQL, non hai tante annose questioni. Esiste
l'utente "root" senza password, accessibile da chiunque. Creare un utente con
restrizioni di accesso e' lungo come battere UNA istruzione di grant...


[...]
> Beh, insomma....
> Condivido che si possa sopravvivere senza averle, e posso capire che ci 
> siano dei contesti in cui la velocità di esecuzione o la solidità siano 
> l'obiettivo prioritario; condivido anche pienamente che mysql adempia 
> eccellentemente alla sua missione: solido, veloce, molto integrabile...
> Però rimango del parere che ci siano non pochi contesti in cui queste 
> features siano essenziali.
> Tant'è vero che gli annunci successivi le comprendono.

Gli annunci "successivi" (che ormai sono attuali, perche' come vedi le foreign
keys e l'integrita' referenziale, come le cancellazioni a cascata, sono gia'
qui) sono arrivati perche' degli utenti, che pagano un supporto commerciale,
le hanno volute. Come dire, se mi paghi io te lo implemento, ma sempre
rispettando una certa filosofia: non si mette una feature se mi fa degradare
le performance o la stabilita'.

D'altro canto, io so che moltissimi (la gran parte degli ISP, visto che la
versione Max e' ancora assai poco diffusa) compilano MySQL escludendo
esplicitamente innodb, per esempio.

Ripeto, se ti serve un DB totalmente ANSI e che supporti certe cose, allora
NON devi guardare, molto probabilmente, a MySQL.


[...]
> Non lo metto in dubbio.
> Ma a costo di molta complessità in più.

Non sono d'accordo. O meglio, a volte e' vero, ma *non sempre*. Io credo che,
in fondo, la complessita' sia sempre la stessa, solo che la sposti da una
parte all'altra: dipende unicamente da dove la mettii. Quello che non fa il DB
lo fa l'application server, e viceversa.

Cosa mettere e dove, dipende dai requisiti utente che hai. Dato che la
stragrande maggioranza delle volte, quando scrivi un'applicazione, e'
preferibile essere indipendenti dal database, spesso e volentieri si tende a
"caricare" l'application server (te lo dimostrano i recenti sviluppi
dell'ambiente J2EE: BMP e CMP fanno praticamente anche il caffe', basta che
crei un EJB per ogni tabella, e un XML per ogni relazione tra tabelle...). In
questo contesto moltissime funzionalita' tradizionalmente affidate ai DB
spesso vengono gestite a livello di middleware (anche perche' entrano in gioco
concetti come sessione utente, connection pooling, replicazione dei
datasource, ecc. ecc.). Per esempio, i trigger a livello di DB, che altrove
sono molto utili, in ambito J2EE sono praticamente visti come un elemento
fonte solo di anarchia...

Se invece i tuoi requisiti utente non prevedono tanti fronzoli, e vuoi/devi
"sbilanciarti" lato DB, allora 1) MySQL magari quella certa cosa che ti torna
utile non la fa e 2) anche se la facesse, non sarebbe adatto perche' non e'
fatto per funzionare in quel modo. Altri DB come Oracle e DB2 hanno, rispetto
a MySQL, migliori caratteristiche di stabilita', scalabilita', replicazione
dei dati ecc. ecc. che li rendono molto piu' adatti a certe applicazioni.

Pero' e' anche vero che MySQL costa zero lire...

Se poi si parla di applicazioni simil-Access, non credo che a MySQL manchi
gran che', francamente.


> Anche qui:  non lo metto in dubbio.
> Ma in molti altri contesti mi pare assai deprecabile che per ovviare 
> alla mancanza delle UNION si debba creare una tabella temporanea, 
> popolarla e poi andarsela a rileggere !!

Ti faccio notare una cosa: quando fai una "select ... union" o "select ...
into view" in Oracle o in DB2, il database *crea comunque* una tabella
temporanea in memoria, con tanto di indici.

Con MySQL puoi fare la stessa cosa, puoi creare una tabella hash residente in
RAM e leggertela. La differenza e' unicamente di sintassi, ma tecnicamente
avviene la stessa identica cosa - anzi, in MySQL hai piu' controllo.

Certo, se il modo prediletto dall'utente di usare un DB e' smanettare a
casaccio come si fa in Access, allora MySQL e' sicuramente meno adatto a
generare porcherie...

Quello che casomai manca davvero, e che potrebbero essere davvero utili, sono
le VIEW. Ci saranno, nella 4.1, le "unnamed views" ma le vere views non sono
pianificate prima della 6.0...



[...]
> Beh, insomma, facciamo a capirci...
> Come spesso capita nelle attività umane, ciò che conta è stabilire le 
> priorità.
> Talvolta - per esempio - può essere più importante avere del codice 
> velocissimo.
> Talaltra del codice facile de scrivere e da manutenere.
> La "porcheria" di cui tu parli - ad esempio - è molto useful dal punto 
> di vista della semplicità con cui costruirci sopra delle semplici 
> implementazioni (che credo sia un tilizzo abbastanza tipico di un genere 
> di utenti piuttosto numerosi e - per quel che mi riguarda - 
> rispettabilissimi )

Certo. Ti posso dire la mia esperienza? la mia carriera e' *costellata* di
RISCRITTURE DA ZERO di "creazioni" (diciamo cosi'...) di "utenti
rispettabilissimi" che volevano fare una "cosa veloce" e si sono *legati* a
strumenti *deleteri* come MS Access, che dietro l'iniziale semplicita'
nascondono la NON scalabilita', le PESSIME performance e la NON compatibilita'
con il resto dell'universo.

Io rispetto tutti, anche chi non sa manco muovere il mouse. Ma ti rendi conto
che, come professionista informatico, *non posso* NON CRITICARE certi modi di
agire non professionali - anche perche' spesso a promulgarli sono proprio dei
miei "colleghi". Sarebbe come chiedere ad un medico di rispettare chi va a
farsi curare dall'esorcista, non trovi?


[...]
> Se non ricordo male nella 3.x dovevi usare l'innodb, nella 4.0 invece è 
> compreso di base.

Perche' innodb e' incluso di base ;-)


[...]
> >Eh?!? e che c'entra MySQL? direi che e' un problema di PHP, non certo
> >del database!!!
> >  
> >
> Perchè ?
> Se io ho uno script php che usa in una query una UNION, ritengo che sia 
> necessario che il mysql a cui è agganciato la supporti, o sbaglio ?

Se hai scritto delle select che funzionano con MySQL, funzioneranno con MySQL
3.x, 4.0, 4.1, 5.0.... io intendevo dire questo. La compatibilita' tra diversi
database e' un miraggio a cui si e' creduto solo nei primi 10 minuti in cui e'
apparso :-P



[...]
> Ma fuor di facezia: questa risposta mi interesserebbe sul serio: in cosa 
> consisterebbe questa mia eresia (quest'ultima di postrgres, intendo) ?
[...]

postgresql e' sostanzialmente piu' "pesante" e complesso di MySQL, in sostanza
per applicazioni web e' spesso meno adatto, fino a qualche versione fa non era
manco un gran che' affidabile.

La differenza sostanziale con MySQL e' la filosofia: dove in MySQL non si
aggiunge una feature se questa compromette l'efficienza e la stabilita' (per
questo sono lenti ad aggiungerle), in postgresql si sono previste fin
dall'inizio tutte le features, e si va ora (faticosamente) ricercando la
stabilita'... quindi fai la tua scelta in base a questo :-)

Ci sono poi state, in passato, considerazioni accessorie circa le licenze,
adesso superate perche' MySQL e' diventato GPL.


ciao


-- 
Marco Ermini
http://macchimacchi.net - ICQ 50825709 - GPG KEY 0x64ABF7C6 - L.U. #180221
Di fronte alle sofferenze del mondo tu puoi tirarti indietro, sì, questo è
qualcosa che sei libero di fare e che si accorda con la tua natura, ma
precisamente questo tirarsi indietro è l'unica sofferenza che forse potresti
evitare. (F. Kafka)