[DELPHI] Soluzioni "multi database" per gestionale

[gian55]

Mi è stato commissionato un nuovo gestionale e, dato che in 23 anni di esperienza su gestionali per diversi clienti ho sempre usato database "consigliati" dai clienti, oggi ho modo di scegliere quale database utilizzare e sono indeciso, appunto per questo vorrei svilupparlo senza "legarmi" troppo al db e realizzare un sw indipendente dal db che sia mysql, sqlserver, mdb, firebird, etc.

Non avrò grosse mole di dati nè di traffico quindi non ci saranno problemi di prestazioni.

Mi piacerebbe conoscere le vostre esperienze su queste problematiche:
- quale tecnologia usare? (odbc, unidac o componenti similari,etc?)
- come gestire differenze tra varie sintassi sql? li gestisco condizionalmente nel codice o ci sono modi più furbi?
- tanto lavoro in più per non nulla? (ovviamente non pagato)

Grazie a tutti

giancarlo


ps: utilizzerò delphi7 o delphi2010+fastreport

[alka]

Originariamente inviato da gian55
- quale tecnologia usare? (odbc, unidac o componenti similari,etc?)

Utilizzerei semplicemente la libreria dbExpress, in quanto non presenta problemi particolari con i requisiti che hai posto, possiede driver per la maggior parte dei database in circolazione ed è la libreria che viene supportata, ampliata e regolarmente integrata da chi produce Delphi.

Inoltre, ti lascia una porta aperta verso DataSnap e la condivisione distribuita dei dati.

Originariamente inviato da gian55
- come gestire differenze tra varie sintassi sql? li gestisco condizionalmente nel codice o ci sono modi più furbi?

Se utilizzi dbExpress, dal lato dell'applicazione la sintassi è "uniforme", indipendente dal DB.

Se invece hai necessità di inserire elementi all'interno dei database che intendi supportare, le differenze sono quelle "naturali" che ci sono tra gli standard SQL che ciascun database adotta.

Originariamente inviato da gian55
- tanto lavoro in più per non nulla? (ovviamente non pagato)

Per un'applicazione gestionale, le tue richieste rientrano nell'ordinaria amministrazione.

Originariamente inviato da gian55
ps: utilizzerò delphi7 o delphi2010+fastreport

Meglio Delphi 2010, che è Unicode e possiede parecchi "bug fixing" a RTL/VCL, oltre ad un IDE con infinite funzionalità in più, soprattutto dal lato della "produttività" che mi pare di capire non sia un tema secondario per te (sono talmente tante che è quasi impossibile riepilogarle, anche perché ci sono più di 10 anni di storia di Delphi in mezzo).

Ottima la scelta di FastReport, che è senz'altro tra i tool più blasonati.

Ciao!

[gian55]

Grazie Marco,
i tuoi post o commenti sono sempre molto apprezzati...dai primi tempi del newsgroup di Cantù...e se non sbaglio ci siamo anche incontrati in qualche presentazione delle varie versioni di Delphi

In merito alla tua risposta, ho ancora un dubbio di come gestire piccole differenze SQL, oppure con dbexpress non me ne devo preoccupare?
Qualche piccolo esempio di differenza tra vari db:
mdb: top
sqlserver: top
mysql: limit
firebird: first

mdb: now
sqlserver: getdate
mysql: now

mdb: boolean True/False oppure -1/0
sqlserver: bin "True"/"False" oppure 1/0
mysql: tinyint 0/1

Grazie ancora del tuo aiuto e complimenti.

[alka]

Originariamente inviato da gian55
Grazie Marco,
i tuoi post o commenti sono sempre molto apprezzati...dai primi tempi del newsgroup di Cantù...e se non sbaglio ci siamo anche incontrati in qualche presentazione delle varie versioni di Delphi

Grazie mille! E speriamo di vederci anche alla prossima occasione.

Originariamente inviato da gian55
In merito alla tua risposta, ho ancora un dubbio di come gestire piccole differenze SQL, oppure con dbexpress non me ne devo preoccupare?

Riguardo i tipi di dati, chiaramente non è conveniente che tu scelga tipologie che esistono in un database piuttosto che un altro.

In relazione invece a TOP, LIMIT e altre clausole simili, dbExpress supporta un proprio standard (vicino allo standard SQL più comune) e traduce le richieste in base al database di riferimento; in ogni caso, avendo a che fare con DataSet unidirezionali, alcune funzionalità come paginazioni o pacchettizzazioni si ottengono facilmente anche lato client tramite ClientDataSet, qualora trasferirle sul client non sia un problema (in termini di performance o altro).

In ogni caso, prova a fare qualche ricerca in merito, scarica una trial di Delphi e realizza qualche prototipo, che senz'altro è il modo migliore di chiarire e verificare nella pratica i tuoi dubbi specifici.

Ciao!

[deleted_29]

Originariamente inviato da gian55

In merito alla tua risposta, ho ancora un dubbio di come gestire piccole differenze SQL, oppure con dbexpress non me ne devo preoccupare?
Qualche piccolo esempio di differenza tra vari db:
mdb: top
sqlserver: top
mysql: limit
firebird: first

mdb: now
sqlserver: getdate
mysql: now

mdb: boolean True/False oppure -1/0
sqlserver: bin "True"/"False" oppure 1/0
mysql: tinyint 0/1

Grazie ancora del tuo aiuto e complimenti.

Vabbè ti dò i miei consigli, che notoriamente non sono sempre apprezzati

libreria? ZEOS. Non solo funziona bene (da D5, io spesso uso proprio quello!), non sono solo è open, ma ne trovi un port perfino per lazarus, casomai ti capitasse di dover fare programmelli linux-mac

db? [ecco che stanno per partire gli strali...] non usare nessuna delle cose "strane".
niente limit, niente now, niente getdate, niente boolenani (per inciso in mysql si può usare un "enum"), a favore del magnifico integer (che ti frega di usare tinyint? niente, se il db è piccolo)


I "trigger" li metti direttamente nei componenti delphi (zeos).
Anzi meno ne usi meglio è (più è dentro l'applicazione meno è difficile portarla)

Niente funzioni "strane", solo SELECT, UPDATE e INSERT "lisce".
Puoi portare tutto il resto lato applicazione, con gran facilità in delphi.

Qualche suggerimento sparso
1) creati una funzione tipo XSQL(i_tipodatabase:string;i_componente... i_query:string;i_readonly:boolean (...)

alla quale passi esplicitamente il tipo del DB che usi ('MYSQL', 'POSTGRES', 'FB'), e dentro ci metterai le sintassi precise per i vari db

2) creati funzioni datatodatasql(i_tipodatabase:string;i_data:tdate): string
e timetotimesql(i_tipodatabase:string;i_time:ttime): string che
convertono date e ore nel formato del db che usi (questa è una di quelle cose che "salvano la giornata")

3) come sopra per funzioncine tipo settacampobool e leggicampobool (se proprio non vuoi eliminarli tutti a favore di integer)

4) (-altra cosa estremamente utile) due funzioni settacampocurrency e leggicampocurrency.
I $$$ sono un altro dei campi notoriamente "rognosi" da gestire (arrotondamenti euro e così via)

Poi vedi te... io non ho una gran esperienza in queste cose...

PS E soprattutto NIENTE campi autoincrementanti.

---
Per quanto riguarda fastreport... lo uso da una vita, ha pregi e difetti; fai attenzione in particolare al difetto peggiore (a mio avviso), ossia l'esportazione PDF che diventa pessima usando campi con HTMLTags attivi (diventano immagini anzichè testo!)

Dal momento che oggi il 99.9% delle stampe è richiesto pure in PDF, o fai particolare attenzione a NON usare le htmltags, oppure ti tocca usare un PDFCreator per le esportazioni, altrimenti (con grandi report) ti trovi con file di decine o centinaia di MB come nulla

[gian55]

Grazie Franzauker,
ho apprezzato molto i tuoi consigli...anche perchè (zeos a parte con cui ci ho litigato un paio di volte ma con vecchie versioni), alcune tue soluzioni le ho già implementate questa mattina nelle prove che sto facendo per valutare la strada da iniziare, ovvero delle funzioni da "incastrare" nelle query per formattare valuta, campi bool (gestiti come int), differenze (top,limit,first) cosi' in fase di configurazione mi definisco quale db uso e condiziono le risposte delle funzioni per il corretto SQL che mi serve.
Non ho per ora trovato alcun problema a gestire ID autoincrementati, perchè li sconsigli?
Sommariamente non ho riscontrato problemi gravi con le soluzioni sopra elencate (stesse dei tuoi consigli) se non con delle tabelle con date all'interno; mysql,access,fb le digeriscono bene mentre usando ms sqlserver ho valanghe di eccezioni sul tipo di campo non corretto...ma ripeto solo connettendo una tabella e relativa dbgrid. Questo mi sta facendo impazzire...non capisco dove sia il problema....in tutti i db ho usato un semplice "datetime".
Qualche idea?

Grazie ancora

ps: zeoslib è morto o semplicemente fermo al 2010 o passato a fork altrove? su http://sourceforge.net/projects/zeoslib/files/ ho trovato solo build del 2009. grazie

[gian55]

dimenticavo...riguardo a fast report mi trovo bene...dalla prima versione...ovvio che è un compromesso tra prezzo e qualità...hai ragione pdf enormi ma cmq accettabili, mentre quello che trovo osceno è l'esportazione doc o xls...disastroso.
sono in attesa da 1 anno della versione 5 che continuano a rimandare... non vedo l'ora di usare i qrcode e datamatrix che dovrebbero essere integrati come anche esportazioni migliori.

grazie

[alka]

Originariamente inviato da franzauker
Vabbè ti dò i miei consigli, che notoriamente non sono sempre apprezzati

Oh, quanto sei prevenuto.

Mi paiono buoni consigli se si vuole seguire una strada alternativa rispetto a quella proposta "in the box" da Delphi (in certi casi, valgono anche se si usa dbExpress).

[deleted_29]

Originariamente inviato da gian55
...Non ho per ora trovato alcun problema a gestire ID autoincrementati, perchè li sconsigli?

Perchè non esistono, nativamente, in tutti gli RDBMS.
In particolare nei due "più" interessanti, firebird e postgres (per la "rivendibilità" senza pagare licenze) non esistono, e bisogna simularli con le sequenze.
Cosa che si può fare, ovviamente, ma è uno smarronamento immane (=qualsiasi cosa richieda più di 4 secondi per me)

...ms sqlserver ...

AHEM...
Mi spiace ma non uso merda (volevo dire software) microsoft se non strettamente costretto...
Sono la persona sbagliata cui chiedere qualcosa per sqlserver (che, in realtà, NON è farina del sacco di zio bill, il che spiega vagamente perchè funziona), sorry

ps: zeoslib è morto o semplicemente fermo al 2010 ...

Non ti so dire, io uso la 6.6.5 da parecchio, può essere

dimenticavo...riguardo a fast report mi trovo bene...dalla prima versione...ovvio che è un compromesso tra prezzo e qualità...hai ragione pdf enormi ma cmq accettabili, mentre quello che trovo osceno è l'esportazione doc o xls...disastroso.

Da lunghissimo tempo lascio perdere DOC e XLS (... come mai? ), al massimo per XLS esporto i tdataset direttamente via COM con Excel, cosa sempre richiesta dai clienti

sono in attesa da 1 anno della versione 5 (...)

Tra gli strumenti di reportistica (coi suoi difetti) è pur sempre il mio preferito
Spesso mi ripropongo di metter mano al sorgente per dargli una "sistemata", ma poi... soooo piiigrroooooo...

[deleted_29]

Originariamente inviato da alka
Oh, quanto sei prevenuto.

parola d'onore che non è un mio clone che mi sono fatto per darmi autoragione


PS anche perchè ho SEMPRE ragione
questa è ironica, spero si capisca