Consigli su database da interfacciare a Delphi

[colde]

Ciao a tutti,
a breve dovrò implementare la mia applicazione scritta in delphi con l'interfacciamento di un DB per la gestione dei dati. Premetto che il DB verrà installato in locale e sarà interfacciato ad un server con MySQL installato e lo scambio dati avverrà tramite XML. Il DB deve essere necessariamente veloce anche con una grossa mole di dati da gestire, facile da distribuire e installare, deve avere la possibilità di importare file SQL e di interpretare correttamente l'SQL di MySQL.
Detto questo, sarei indeciso tra Postgree e MySQL; il primo non lo conosco ma credo sia uno dei più usati DB interfacciati a Delphi ed è in stile access (intendo dire che il DB viene gestito tramite unico file, non come MySQL) mentre il secondo lo uso da qualche anno ma avrei sicuramente qualche difficoltà per la distribuzione e installazione automatica.

Voi cosa mi consigliate?
Grazie mille

[fastcoder]

Se i costrutti SQL che usi non sono proprietari di MySQL (cosa che ovviamente ti costringe ad usare quest'ultimo)...io darei una occhiata anche a SQLite.
In fondo se lo usi in locale (se ho ben capito il server MySQL di cui parli non venga usato direttamente dal client, ma abbia un protocollo di scambio dei dati ad hoc con XML), vuoi solo un file che contenga il DB, deve essere molto veloce, non richiedi gestioni particolari (tipo replicazione, un DB orientato agli oggetti, etc)...SQLite potrebbe essere una valida alternativa.
Per usarlo con Delphi però non so cosa implichi...credo che ci sia una qualche suite di controlli integrata nel sistema dei Dataset (controlla il link SQlite 4 Delphi ).
Io l'ho usato direttamente da C e l'ho trovato molto semplice da usare (ripeto per gestioni DB non troppo sofisticate).
Per l'installazione poi non serve neanche...basta una DLL.

Spero di non averti complicato ulteriormente la scelta

[alka]

Originariamente inviato da colde
Premetto che il DB verrà installato in locale e sarà interfacciato ad un server con MySQL installato e lo scambio dati avverrà tramite XML.

Immagino che i dati verranno passati dalla tua applicazione...

Originariamente inviato da colde
Il DB deve essere necessariamente veloce anche con una grossa mole di dati da gestire, facile da distribuire e installare, deve avere la possibilità di importare file SQL e di interpretare correttamente l'SQL di MySQL.

Con le caratteristiche che hai elencato, soprattutto l'ultima, la tua unica soluzione è MySQL, in quanto nessun altro DB ti garantisce la piena compatibilità nei costrutti.

Non capisco, a questo punto, quale sia il ruolo dello scambio dati XML se devi avere due DB che parlano la stessa lingua.

Originariamente inviato da colde
il primo non lo conosco ma credo sia uno dei più usati DB interfacciati a Delphi ed è in stile access (intendo dire che il DB viene gestito tramite unico file, non come MySQL)

Non credo che PostgreSQL sia tra i DB più utilizzati con Delphi, molto più frequente FireBird e lo stesso MySQL.

A parte questo, il fatto che il database organizzi i dati su un unico file o su più file non ha alcuna influenza sul tipo stesso di database: sia PostgreSQL (se non sbaglio) sia MySQL sono database di tipo client/server, quindi sono del tutto paragonabili tra loro, e comunque sono entrambi diversi da Access allo stesso modo.

La differenza di Access rispetto a questi DB risale al fatto che Access è di tipo "file based", cioè basato su file con accesso diretto e fisico dell'applicazione al file dei dati, con tutto ciò che ne consegue.

Originariamente inviato da colde
Voi cosa mi consigliate?

Per l'uso con Delphi io suggerisco sempre FireBird in quanto lo ritengo il complemento più adatto a questo ambiente di sviluppo, facile da utilizzare e configurare, con la possibilità di funzionare come server embedded (per l'uso in CD di presentazione o programmi client) e come server vero e proprio, alla stregua di MySQL, con prestazioni elevate e poco invasivo. Inoltre, è freeware e OpenSource!

Ciao!

[colde]

Ciao Alka,
lo scambio dati tra DB server e DB client avviene ovviamente tramite interfaccia software che sto sviluppando; è vero che i dati vengono trasmessi e ricevuti in formato XML ma la necessità di avere DB client compatibile con l'SQL di MySQL deriva dal fatto che è prevista l'esportazione da MySQL dell'intero DB in un file SQL da importare sul client. Se il client non interpreta correttamente le istruzioni rischiamo di avere un DB mal formattato o peggio ancora senza possibilità di importare i dati. E' una situazione un po particolare ma le necessità sono queste. Diciamo che ora sono combattuto tra MySQL e FireBird:

MySQL - mi permette di avere i DB compatibili al 100% ma credo sia difficoltosa la distribuzione;

FireBird - dovrebbe essere più semplice da distribuire ma non è sicuro al 100% che sia compatibile con l'SQL di MySQL;

Quale scegliere a questo punto? Tenendo conto che l'SQL generato da un'eventuale esportazione da server non dovrebbe contenere istruzioni particolari dato che si tratta sostanzialmente di creare tabelle e inserimento di dati.

[alka]

Originariamente inviato da colde
lo scambio dati tra DB server e DB client avviene ovviamente tramite interfaccia software che sto sviluppando; è vero che i dati vengono trasmessi e ricevuti in formato XML ma la necessità di avere DB client compatibile con l'SQL di MySQL deriva dal fatto che è prevista l'esportazione da MySQL dell'intero DB in un file SQL da importare sul client. Se il client non interpreta correttamente le istruzioni rischiamo di avere un DB mal formattato o peggio ancora senza possibilità di importare i dati. E' una situazione un po particolare ma le necessità sono queste. Diciamo che ora sono combattuto tra MySQL e FireBird

Non hai alcuna possibilità di scelta: devi per forza usare MySQL per avere la compatibilità piena degli script, di cui tuttavia ignoro ancora la necessità poiché già che realizzi un software in grado di tradurre dati sottoforma di XML, perché non esprimere tutti i dati in questo formato anche quando è necessario inserire in uno dei due DB una mole ingente di dati, invece di usare statement SQL in chiaro, senza contare che dovrai poi trovarti a gestire alcuni problemini di sincronizzazione poiché alcuni dati potranno essere presenti, altri no.

Originariamente inviato da colde
MySQL - mi permette di avere i DB compatibili al 100% ma credo sia difficoltosa la distribuzione

E' sufficiente installarlo sul client, non che sia così difficoltoso. Certo, rimane senz'altro una pratica più complessa dell'integrazione col proprio programma a livello di installazione, senza la necessità di disporre di un client e di un server.

So che esiste una versione "embedded" di MySQL, ma non ne ho mai fatto uso.

Originariamente inviato da colde
FireBird - dovrebbe essere più semplice da distribuire ma non è sicuro al 100% che sia compatibile con l'SQL di MySQL;
Quale scegliere a questo punto?

Il problema è che, a questo punto, non hai scelta, soprattutto se hai già iniziato ad usare MySQL e vuoi mantenerlo.

Se la necessità - che mi risulta ancora del tutto "fumosa" - di avere script SQL compatibili su macchine differenti è un requisito, usare MySQL senza essere certi di poterlo in futuro adoperare anche sul PC client è stato un errore, poiché avresti dovuto tenere conto prima dello scoglio che avresti incontrato.

Originariamente inviato da colde
Tenendo conto che l'SQL generato da un'eventuale esportazione da server non dovrebbe contenere istruzioni particolari dato che si tratta sostanzialmente di creare tabelle e inserimento di dati.

Non sono le istruzioni ad essere "particolari", quanto il "dialetto".

I problemi non scaturiscono dal tipo di operazione che devi fare, ma nelle piccole diversità che ci possono essere nell'esprimerle sottoforma di SQL da parte di due database differenti.

Secondo me, se permangono i requisiti che hai elencato, c'è ben poco da fare: ti tocca usare MySQL anche sul client.

[colde]

capisco che la questione import/export può sembrare inutile visto l'uso di XML ma tenendo conto che dovranno essere importate almeno 4 tabelle con ciascuna milioni di dati al loro interno e con parecchi campi, l'uso dell'XML richiederebbe parecchie risorse sia al parser (creato ad hoc per questo progetto) che al server che deve gestire anche il sito. L'unica cosa che posso fare è rivedere questa parte con l'altro tecnico che se ne occupa e valutare le due possibilità tenendo conto anche delle mie esigenze.

Per me in ogni caso sarebbe un enorme problema non includere l'installazione del DB nel setup del mio software in modo da rendere tutto automatico. Il target di questo software non sono dei tecnici informatici quindi non saprebbero da che parte voltarsi e visto che il programma dovrà essere distribuito in tutto il globo vorrei evitare di avere continue richieste di assistenza cercando di renderli il più possibile autonomi e fornendo loro qualcosa di semplice da utilizzare.

[alka]

Originariamente inviato da colde
capisco che la questione import/export può sembrare inutile visto l'uso di XML ma tenendo conto che dovranno essere importate almeno 4 tabelle con ciascuna milioni di dati al loro interno e con parecchi campi, l'uso dell'XML richiederebbe parecchie risorse sia al parser (creato ad hoc per questo progetto) che al server che deve gestire anche il sito.

Le risorse richieste al parser XML dipendono esclusivamente dal tipo di parser.

Se il parser usa un DOM, quindi tenta di costruire una struttura gerarchica dei dati ottenuti, è chiaro che nel caso in cui si parli di milioni di record ci saranno senz'altro problemi di risorse occupate.

Usando invece un'implementazione basata su SAX, ad esempio, quindi un parser che processa nodo per nodo senza creare una cache, problemi di risorse non esistono, è solo una questione di tempo.

In ogni caso, in termini di carico del server, se parliamo di avere a che fare con milioni di record, non pensare che questi possano essere facilmente trasportati in modo compatto via SQL, dato che per ogni record è presente un'istruzione INSERT che, pur essendo meno "verbosa" dell'equivalente XML, non sarà senz'altro leggera.

Quindi, comunque sia, aspettati di avere il server pienamente occupato in entrambi i casi a meno di non adottare soluzioni specifiche e complesse per gestire questa situazione (ad esempio, elaborare record a pacchetti o qualcosa di simile).

Originariamente inviato da colde
Per me in ogni caso sarebbe un enorme problema non includere l'installazione del DB nel setup del mio software in modo da rendere tutto automatico. Il target di questo software non sono dei tecnici informatici quindi non saprebbero da che parte voltarsi e visto che il programma dovrà essere distribuito in tutto il globo vorrei evitare di avere continue richieste di assistenza cercando di renderli il più possibile autonomi e fornendo loro qualcosa di semplice da utilizzare.

In tal caso, dovrai fare i "salti mortali" per installare in modo automatico e trasparente MySQL.