[Primipassi] equivalente di access

[Aldo]

Beh, me l'ero cercata :-)

Comunque:

Marco Ermini wrote:

>ci sono svariate interfacce grafiche utilizzabili con MySQL. Hai provato a
>vedere il sito www.mysql.com ? :-)
>  
>
Beh, sì... Come ho detto io per ora sto usando mysqlcc.

>(magari non "performante", ma 
>veloce...),
>  
>
>
>qual e' la differenza tra performante e veloce per te? :-)
>  
>

Beh, diciamo che la risposta dipende dai limiti di cui sopra.
Ossia:
- 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. E 
comunque ancora non ho elementi per dire nulla sulle prestazioni 
complessive.

>
>[...]
>  
>
>>MySQL invece ha ricche (e a volte noiose) possibilità di amministrazione 
>>degli utenti;
>>    
>>
>
>Tutte le funzioni di amministrazione sono noiose, quando non ne capisci il
>significato... allora non hai mai usato Oracle o DB2... :-)
>
>  
>
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) ...

>>MySQL (fino alla 3.23) non supporta tantissime funzioni assolutamente 
>>essenziali:
>>    
>>
>
>NON sono "assolutamente essenziali", altrimenti non lo usarebbe nessuno, non
>credi?
>
>Ti consiglio di rileggere i motivi ispiratori del perche' e per come MySQL e'
>nato e si e' sviluppato in un certo modo: non manca di feature perche' e' "in
>ritardo" ma per precise scelte tecniche, che guardacaso hanno fatto la sua
>fortuna. In effetti lo stai giudicando molto, molto male.
>
>  
>
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.

>>- le UNION (!)
>>- le subqueries (!!!)
>>- l'integrità referenziale  (!!!!!)
>>    
>>
>
>tutte cose che ti paiono essenziali? nel 95% dei casi se subqueries sono
>esemplificabili in altro modo, 
>
Non lo metto in dubbio.
Ma a costo di molta complessità in più.

>e sia le union che l'integrita' referenziale
>sono fattibilissime in altri modi (cosa spesso auspicabile in molti contesti,
>per esempio in application server distribuiti).
>  
>
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 !!

>>- le stored procedures (neppure Access, mi pare)
>>    
>>
>
>Puoi tranquillamente creare delle funzioni in C da linkare al db server. 
>
Non lo sapevo.
Certo che ... ;-)

>>- le transazioni (neppure Access, mi pare)
>>    
>>
>
>Le transazioni sono disponibili sia in MySQL che in Access (ti sei perso
>qualcosa ;-)
>  
>
Può ben darsi... Come vi dicevo è da un paio settimane che abbiamo fatto 
conoscenza io e mysql :-)

>L'unica cosa che sarebbe, casomai, veramente utile e che nessuno dei due ha (e
>che ti sei dimenticato di nominare ;-) sono i trigger...
>
>  
>
Giusto.

>>Access ha una funzionalità che per chi sviluppa in ambito web è magica: 
>>tratta le queries sql come vere e prorpie viste logiche, che quindi 
>>possono essere trattate esattamente (quasi...) come se fossero delle 
>>tabelle;
>>    
>>
>
>e l'utilita' di questa porcheria sarebbe?....
>
>  
>
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 )

>5)
>Access possiede un'interfaccia grafica (ma forse dovrei dire un verio e 
>proprio IDE) che permette di fare un macello di cose (creare reports, 
>forms, macro, etc...)
>  
>
>
>...e permette anche di *disfare* un sacco di cose... ma soprattutto da'
>l'*illusione* che sia facile (a portata di cani e porci, che poi in effetti
>sono i veri utenti di Microsoft Access ;-) creare un'applicazione
>client/server - salvo poi scoprire che, quando dovrai supportare una
>multiutenza *decente* e il tuo DB crescera' un po', che devi rifare tutto
>daccapo con altri prodotti :-(
>
>  
>
Su questo non solo convengo, ma credevo di averlo già scritto nella mia 
mail precedente.
Giusto per fare chiarezza: io non mi sognerei MAI di usare Access per un 
utilitzzo in multiutenza che vada al di là della vetrinetta web su 
databases da *poche* decine di records e di accessi.

>>Magari esistono aggeggi simili per MySQL, ma io non ne conosco (e di 
>>certo non sarà semplice trovarli/configurarli/usarli).
>>    
>>
>
>Si vede che non li hai mai cercati, se non li conosci... e poi "facile" o
>"difficile" dipende tutto da chi lo fa... sai come si dice, Unix *e'* user
>friendly, e' solo che si sceglie lui amici e nemici ;-)
>  
>
Non discuto.
Come si suol dire... "ubi major..." ;-)

>Hai mai provato ad usare kdevelop o le applicazioni PHP gia' pronte come
>PHPNuke o postnuke?
>
>  
>
No.
Lo farò senz'altro.

>>In sintesi:
>>per me MySQL è stata un piccola delusione... Lo so che la 4.0 ha 
>>introdotto qualcosa (credo le transazioni),
>>    
>>
>
>No guarda, quelle c'erano gia' con la serie 3.x. Non dipende dalla versione di
>MySQL ma dal fatto che utilizzi o meno lo storage innodb.
>  
>
Se non ricordo male nella 3.x dovevi usare l'innodb, nella 4.0 invece è 
compreso di base.

>>E poi: io magari sul mio PC posso sempre downloadare l'ultima versione, 
>>ma se poi scrivo del codice PHP che usa le funzioni dell'ultima 
>>versione, quante speranze ho che sia utilizzabile sui siti web dove poi 
>>andrò a mettere gli scripts ?
>>    
>>
>
>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 ?

>>Ciò che sto valutando adesso ( e su cui chiedo consiglio a voi Guru ) è 
>>di "convertirmi" a PostgreSQL, che sulla carta supera tutte le 
>>limitazioni di MySQL, senza contropartite (è davvero così ?)
>>    
>>
>
>Senti, ma quali "carte" ti leggi? saranno mica quelle su cui poi ti ci
>arrotoli quella roba che ti fumi (e passala, dai!!! non fare il bastardo ;-)
>
>  
>
Beh, volentieri, quando ci capiterà di incontrarci :-)
Ma fuor di facezia: questa risposta mi interesserebbe sul serio: in cosa 
consisterebbe questa mia eresia (quest'ultima di postrgres, intendo) ?

>  
>
>>Se non quella di essere meno diffusoi, almeno rpesso gli ISP, e quindi 
>>con ancora più problemi di portabilità rispetto a MySQL 4.x
>>    
>>
>[...]
>
>Senti, ma di quali problemi di portabilita' vai parlando? hai avuto problemi
>in questo senso? io francamente, mai. A maggior ragione con PHP di mezzo.
>  
>
Beh, sì...

>Al limite, quello che fa veramente casino e' quando devi mettere un DB Access
>presso un ISP su Windows (tra MDAC, Service Pack e porcherie simili, e il DSN
>che deve per forza fartelo l'ISP... quella roba la' si' che non funge mai!)
>
>
>  
>
Vero, vero...

Ciao
Aldo