Newsgroup: it.comp.lang.delphi
Titolo: [Forse OT] Delphi, dbExpress e MySQL: un terzetto diabolico?

Ho sviluppato e distribuito già da un pò un gestionale sviluppato usando
Delphi 6, dbExpress come componenti per l'accesso ai dati e MySQL ver
4.0.18, il tutto ovviamente in ambiente Windows.
Premetto fin da subito che non cerco soluzioni ad un particolare problema,
anche perchè non riesco a definirlo il problema, ma mi interessa invece
sapere se qualcuno ha avuto esperienze simili alle mie sotto riportate.
A parte le difficoltà incontrate con l'SQL piuttosto spartano di MySQL, a
grandi linee tutto sembra andare bene, a parte alcuni sporadici e non
ripetitivi casi di delirio non so se di MySQL o delle dbExpress, che ogni
tanto non eseguono alcune query di inserimento o di modifica.
Per esempio, in conseguenza di una procedura di inserimento a magazzino di
prodotti ordinati mi vengono generati  i movimenti ma non vengono aggiornate
le giacenze (sporadicamente), e nel log delle query effettuate sono presenti
tutte le query.
Ci tengo a precisare che non potendo fare uso delle subquery molte
operazioni le ho dovute spezzettare utilizzando tabelle di appoggio e così
eseguo molti passaggi anche per operazioni relativamente semplici.
Mi sono convinto che MySQL non sia il database adatto per applicativi
gestionali, ma il suo impiego va limitato a database server per siti web.
Voi che ne pensate? avete esperienze simili alla mia o le vostre apps com
MySQL funzionano tutte alla grande?
Ciao.
Roberto

 
Jeremy,
	la mia esperienza con MySQL, a prescindere dai problemi che hai, è 
molto simile alla tua. Nel senso che MySQL l'ho usato in molti ambiti, 
sia web con accesso PHP sia per lavori più "seri" con Java (sinceramente 
mai con Delphi).
	Il vero problema di MySQL è che nasce come engine molto semplice. Le 
caratteristiche tipiche di un DB come le transazioni, le subquery, 
trigger e stored procedure non sono mai state implementate se non 
nell'ultimo anno. Questo rende frustrante creare applicativi "seri".
Il vantaggio di questa struttura, comunque, era una eccezionale velocità 
di risposta del server (non dovendosi preoccupare di molti problemi....).
	Ora la casa che lo sviluppa sta cercando di trasformarlo in un DB 
serio. Già le versioni attuali, sfruttando le tabelle Berkeley o Inno ti 
possono dare le transazioni. Per subquery, trigger e stored procedure 
dobbiamo aspettare la prossima versione (e un po' perché si stabilizzi).
	Personalmente trovo molto frustrante dover generare molte più query, 
tabelle d'appoggio (anche se temporanee) per fare cose che normalmente 
con Firebird si fanno con una singola query. Ti consiglio, se hai la 
possibilità in futuro di usare questo DB. Possiede tutte le 
caratteristiche che ti ho elencato e in più la sua versione "embedded" 
può girare come una singola DLL del tuo applicativo.
	Nei miei progetti, quando ne ho di nuovi, consiglio ai clienti o 
Postgres o Firebird come soluzioni free, e fino ad ora, mi sono trovato 
molto bene.
	A presto!
	Gian Luca

[SNIP]
IMHO: Meglio Access di MySQL.
Ci sono parecchie cose di MySQL che non mi piacciono, a
cominciare dalla documentazione( schifosissimo formato HTML,
pessimamente organizzato in un UNICO file che contiene tutto ).
Secondariamente, leggendo la documentazione si nota che se un
campo č richiesto, ma nella query non c'č, ebbene... si solleva un
errore? NO! Viene attribuito un valore di default al campo: ma non solo.
Nel caso si tratti di domini custom, il valore di default non č anch'esso
custom, ma quello che viene utilizzato per il dominio di partenza.
Quindi, potenzialmente sballato.
Altra cosetta: gli strumenti di amministrazione fanno abbastanza
schifo, compreso MySQL.exe - sostanzialmente ingestibile.
Terza cosa, credo una delle peggiori, č che il formato di DEFAULT
delle tabelle č MyTable e non INNODB e questo č *male*.
Quarta cosa: la licenza non č assolutamente chiara. Dovrebbe
essere ristrutturata con un "wording" meno generale e piů
specifico.
Stavo portando avanti un progetto con MySQL per un cliente
( che poi ha deciso di mettere in stand-by la cosa per motivi
economici  - condoni e varie ), e dopo essermi ben letto il
"manuale"( chiamiamolo cosě per pietŕ ) ho pensato due
cose:
1) O sono impazzito io, quindi ho una percezione alterata della
     realtŕ e non capisco come si possa utilizzare un aggeggio
     siffatto anche solo per un sito Web un attimo piů serio,
2) O sono impazziti quelli che lo usano per scopi "seri".
Ci sarebbe anche una terza ipotesi che credo valga la pena
considerare, e cioč che la maggior parte dei siti non sono seri <g>.
Veramente, guarda, meglio Access che MySQL.
Ciao,
Andrea
P.S. Chi mi conosce SA quanto ami Access...

 specifico.
Su questo sono d'accordo.
Inoltre sono d'accordo sul fatto che mysql č fatto per determinate cose e
non per altre, come progetti tipo gestionali o robe del genere. Per quelli
c'č firebird.
Access, invece, io lo tengo buono solo per applicazioni monoutente, e
*basta*, e solo perché non so usare ancora firebird embedded ;)
Inoltre, IMHO, con mysql č meglio usare gli zeos o mysqldac, perché
dbexpress non mi ha mai ispirato molta fiducia...
--
Jax
====
Di sincero, nelle nostre preghiere, c'č solo il desiderio d'esser al
piů presto esauditi.

 dbexpress non mi ha mai ispirato molta fiducia...
Io invece, dopo un pò di macelli, sono riuscito a far funzionare DBExpress
ottimamente. Gli Zeos per me sono stati un incubo invece.
Ciao,
Andrea

Veramente, guarda, meglio Access che MySQL.
eeEEEHhh ?!?!
Ma cosa stai scrivendo, "MySql Trash:la saga dell'orrido" ??
Ti stavo replicando punto punto su tutti i tuoi pensieri... ma questa frase li
supera tutti! altro che "macelli" e "incubi"... con questa affermazione hai
perso 100 punti....
Basito.
-- 
Morde. (
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/
Firefox, il miglior browser: 
http://www.gxware.org/mozilla/

 tutte le query.
dbExpress e MySQL avranno i loro difetti, ma prima di incolparli di "bachi"
nelle logiche applicative dei propri programmi ci penserei 70 volte.
Dubito molto che i problemi che tu hai siano dovuti a "deliri" da parte di
MySQL o dbExpress, anche perché questo sottointenderebbe una intelligenza
propria di questi software, capaci di riconoscere che stai gestendo un
magazzino e così, tanto per farti un dispetto, di non aggiornarti le
giacenze.
Prova a riguardare lo schema dei dati e a controllare per bene il tuo
codice.
MySQL come tutti i software avrà pure i suoi ambiti di applicazione precisi,
ma non dimenticarti che è uno di db più utilizzati al mondo.

> IMHO: Meglio Access di MySQL.
ROTFL!

 > IMHO: Meglio Access di MySQL.
Andrea, la tua affermazione è sicuramente frutto in una momentanea 
.zzatura nei riguardi di MySql che, pur essendo un prodotto che 
personalmente non mi piace, non può essere paragonato a quella 
caricatura di db che zio billy tenta di propinarci da anni come 
alternativa leggera al loro (x molti dannato...) sql server.
Di MySql odio i limiti (niente stored proc, niente generators...)
Di M$Sql che dire?
Ho sentito cose abbastanza racapriccianti sul suo conto, senza contare 
che, x quel poco cne ne so, anche questo prodotto non ha una cosa tipo 
generators di ib/fb oppure le sequences di papa' Oracle, cosa che 
costringerebbe noi poveri cristi a usare i campi autoinc (che ho sempre 
detestato) e leggere poi l'ultimo valore assegnato dalla sessione 
corrente con select @@identiy o una cosa simile...
Ma, mi chiedo, che ti frega dei 2 *sub-db* in oggetto quando firebird ha 
tutto, compreso una versione embedded??
A

 A
Andrea

brilli manco quello.
In cosa, di grazia?
-- 
"La velocità luce non è sufficiente Comandante Nunziatella, 
dobbiamo passare alla velocità smodata!"

corrente con select @@identiy o una cosa simile...
Questo è l'unico vero problema di MSSQL.


 nelle logiche applicative dei propri programmi ci penserei 70 volte.
Hai perfettamente ragione, infatti io non accuso nessuno se non la mia
imperizia, che dopo circa un anno di utilizzo del suddetto DBMS non ho
ancora compreso in tutta la sua complessità.
Eppure comportamenti anomali ne ho riscontrati.
Tra i più comuni, i sibillini messaggi di errore (ritengo delle dbExpress):
"Unable to execute queries"... Cosa vuol dire? perchè "unable to execute
queries"?
E perche se all'interno di un loop eseguo degli insert come mi succede se
carico linee di dati da un file esterno dopo un pò il database si "siede" e
rimane bloccato per 4 o 5 min?
E perchè la stessa identica sequenza di queries funzionava perfettamente
nella versione 4.0.12, passando alla 4.0.16 provocava dei "danni" nei table
handlers (che manco so cosa sono), per poi tornare a funzionare (quasi
sempre) nella 4.0.18?
E' molto probabile che la maggior parte di questi problemi sia dovuta alla
mia scarsa conoscenza di MySQL, ma io ritengo che la versione win sia un
"pochino" meno stabile della nativa versione linux, e comunque adesso ho
chiaro che l'ambito di utilizzo di MySQL è esclusivamente database server
per siti web, e non per apps win32.
Il mio motore di database ideale deve richiedermi solo conoscenze di SQL per
la modifica dei dati e occasionalmente la modifica della struttura, e non le
conoscenze di un analista di sistema: devo tornare ad Access?

Scusa, RobyOneKenoby = Jeremy...
;-)

 In cosa, di grazia?
Enterprise Manager: un incubo. Va bene se devi dare un'occhiata alla
struttura del database, ma già se vuoi scrivere una query tanto per
provare( e NON per ottimizzarla ) fai prima se ti fumi un campo da
calcio ed inizi a cantare come Bob Marley.
Mancano delle classi( almeno, io non le ho trovate, ma potrebbe
darsi che la colpa sia mia ) che ti permettano di fare monitoring
direttamente da applicazione( tipo SQLMonitor, per capirci ).
Non solo, ma a quello che ho capito utilizzando il monitoring non
puoi *filtrare* ciò che è tuo e ti interessa, dal resto!
Ah, ed ovviamente per utilizzare il monitoring DEVI
essere loggato come SA -_-
Se poi devi esportare un database un pò più grande, alleluja!
Lo fai partire prima di pranzo e quando sei tornato sta
ancora lì.
Ogni tanto( senza un'apparente ragione ) la comunicazione col server
rallenta a livelli seriamente inaccettabili( tre secondi per 3 righe di
result set ).
L'SQL non è malaccio purché ci si tenga sullo standard( che più o
meno viene seguito... più o meno ).
Dell'utente SA vogliamo parlarne? Password iniziale vuota( mah! ),
serve praticamente per la maggior parte delle cose che si vorrebbero
fare, a meno di non mettersi lì a sgrugnare 3 giorni sugli users.
Books On Line: marò! Ma, dico, mettere dei tutorial belli in
evidenza no eh?
Tonnellate di documentazione, tonnellate. Però per trovare
quello che cerchi è come partire per il Tempio Maledetto alla
Indiana Jones.
Ecco, ho finito! ^_^
Ciao,
Andrea


Ciao.
P.S. 
NON lavoro per Microsoft, però non sopporto che si critichi a priori
un prodotto solo perché è Microsoft (o altro).

)

 Questo è l'unico vero problema di MSSQL.
occhio: mi sono basato solo su cose note a me personalmente.
Poi, ho amici certificati microsoft che lo usano e mi hanno raccontato 
di cose abbastanza brutte che hanno trovato nelle stored procedure di 
sistema.
e non sono al corrente dei prezzi.
Certo, se costa quanto Oracle.....
Un db che ho usato con soddisfazione in passato è Sybase.
A

A
-- 


 ma non dimenticarti che è uno di db più utilizzati al mondo.
E' proprio questo lo scopo del mio post. So perfettamente che è usatissimo
come database server nei siti web per la sua velocità e per il suo
fantastico sistema di gestione degli account, ma quanti in questo NG lo
usano come motore di db in gestionali client/server sotto Windows?
E tra questi nessuno ha avuto problemi?

 un prodotto solo perché è Microsoft (o altro).
Mi hai mai sentito fare affermazioni del genere?
Andrea

 E tra questi nessuno ha avuto problemi?
Come mai SAP ha scelto per il suo gestionale MySQL?
http://www.sapdb.org/
Giovanni Caramia

 Come mai SAP ha scelto per il suo gestionale MySQL?
Interessante, non lo sapevo, e se lo ha scelto Sap, buona camicia a tutti.
:-)
Comunque come rispondevo ad Andrea Laforgia non escludo che il problema nel
mio caso sia proprio io, cioč la mia non perfetta conoscenza di MySQL e che
sotto windows MySQL abbia bisogno di essere "tarato" con i suoi 150 mila
parametri in modo a me sconosciuto mentre sotto linux probabilmente č di piů
facile ed immediato utilizzo.
D'altro canto le risposte ottenute dal mio post in questo NG mi fanno capire
che non sono in molti ad aver adottato MySQL come motore db client/server
per apps win32 (a parte Sap), anzi, direi che ci sono soltanto io, il che mi
porta a supporre che non č proprio una scelta felice.
By the way, sto lentamente passando a Firebird...

 che non sono in molti ad aver adottato MySQL come motore db client/server
Infatti, a parte te, la Zucchetti
(
http://weekit.mytech.it/weekit/unico/art006004037963.jsp
), la NASA
(
http://www.mysql.com/news-and-events/news/article_51.html
), la Texas
Instruments (
http://www.mysql.com/news-and-events/success-stories/ti.html
),
la Ericsson
(
http://www.mysql.com/news-and-events/success-stories/ericsson.html
) e un
buon centinaio di altre aziende...

 buon centinaio di altre aziende...
Evidentemente non mi sono spiegato....
Io mi riferisco a programmatori PRESENTI in questo NG, con i quali poter
confrontare le esperienze.
Ripeto: Mi sembra di essere l'unico in questo NG ad aver adottato MySQL com
motore db per gestionali client/server in Windows, perchč se ce ne fossero
altri, mi avrebbero risposto e avrei potuto capire se sono io cretino o se
anche "loro" hanno avuto problemi o se piů probalěbilmente MySQL sotto
Windows vada "curato" con settaggi di parametri a me sconosciuti. Sia la
seconda e la terza ipotesi non tornerebbero a buon credito di MySQL in
quanto non immediatamente stabile. Ma questo non lo sapremo mai.
Lo scopo del mio post non era quello di sparare a zero su MySQL, ma di
confrontare esperienze con altri addetti ai lavori che lo utilizzano come lo
utilizzo io.
Invece sapere che grandi colossi tipo Nasa o Texas Instruments lo hanno
adottato sicuramente pagando contratti d'assistenza milionari non mi č di
nessun aiuto...

 nessun aiuto...
Dovrebbe farti pensare, invece...

 contabilita' ordinaria di una gestione aziandale.
Ciao.
Finalmente qualcuno.
E tu non hai mai riscontrato problemi? il tuo modulo di contabilità è sotto
Windows?
Se non hai esperienze particolari di problemi riscontrati con MySQL allora
dovrò tristemente pensare che il problema è solo mio e chiuderò una volta
per tutte questo post off-topic.
Ciao

 
Ciao. volevo anch'io postare la mia esperienza. io ho realizzato un 
piccolo gestionale (contabilità, fatturazione e magazzino) con access e 
mysql. in locale può girare su access e mysql, e quando  collegato ad 
internet gira con mysql installato su linux. il collegamento ad database 
è stabilito in entrambi i casi con ado (versioni 2.5 e superiori) e 
myodbc. io non ho riscontrato i problemi di cui parli, le uniche cose 
che posso riferire sono un comportamento meno performante di mysql 
quando gira sotto win rispetto alle stesse operazioni eseguite sotto 
linux, e ogni tanto un errore sporadico restituito da myodbc "lost 
connection during query". per il resto funziona correttamente da mesi.
spero di essere stato utile. :-)
a presto.
alex.

ho fatto sviluppo con le versioni 3.23.41 e 3.23.52