ADO o DBX utilizzando Delphi

StackOverflow https://stackoverflow.com/questions/1305531

  •  19-09-2019
  •  | 
  •  

Domanda

Che è meglio (e per quali motivi) da utilizzare per connettersi a MS SQL, Oracle o Firebird da un'applicazione Delphi Win32 - ADO o DBX (Database espresso)

?

Entrambi consentono di collegare le principali database. Mi piace il modo ADO fa tutto con un cambiamento stringa di connessione e il fatto che ADO ei driver sono inclusi in Windows quindi nulla in più per distribuire (sembra, correggimi se sbaglio).

DBX è anche flessibile e posso compilare i driver nella mia app, non posso?

Sono davvero entusiasta di avere una sola fonte, se possibile, con la possibilità di variare i database a seconda del reparto IT / preferenze del cliente.

Ma che è più facile da programmare, si comporta meglio, utilizza la memoria in modo più efficiente? Eventuali altre cose per differenziarli su?

Grazie, Richard

È stato utile?

Soluzione

ADO è semplice da usare ed è lì, è solo necessario assicurarsi di installare il driver client correponding nel lato client.

Ho trovato DBX più flessibile ed è meglio integrato all'interno IDE e un altro tecnologie come DataSnap.

Per lo stesso scopo di te, ho usato DBX con i driver di terze parti da Devart . È possibile compilare i driver con l'applicazione se si acquista i sorgenti dei driver.

Altri suggerimenti

All'inizio di Delfi, la gente ha elogiato il supporto multi-DBMS in Delphi. Tutti amavano il BDE (perché quello era l'unico modo per farlo).

Ma quando guardando i clienti su più quindi ultimi dieci anni, ho visto una diminuzione costante di supporto multi-DBMS nelle loro applicazioni.

Il costo di supportare più DBMS da un'applicazione è alta.

Non solo perché si deve essere a conoscenza di ogni DBMS, ma anche perché ogni DBMS ha una propria serie di peculiarità, in cui si deve adattare nel vostro strato di accesso ai dati. Questi non solo includono le differenze nella sintassi e alla base tipi di dati, ma anche strategie di ottimizzazione.

Inoltre, alcuni DBMS funzionano meglio con ADO, un po 'meglio con un collegamento diretto (come saltare il client di Oracle tutti insieme).

Infine testare tutte le combinazioni di software con più sistemi DBMS è molto intenso.

Sono stato coinvolto in alcuni progetti in cui abbiamo dovuto cambiare il backend DBMS e / o la tecnologia di accesso ai dati (da ossia BDE a DBX, o da DBX a una connessione diretta). Cambiare il backend sempre stato molto più doloroso che cambiare la tecnologia di accesso ai dati. approcci multi-tier li ha resi un po 'più facile, ma sono aumentati i gradi di libertà e per questo gli sforzi di test.

Alcuni dei prodotti che faccio vedere che il supporto multi-DBMS sono in applicazioni verticali di mercato in cui il cliente finale ha già la propria infrastruttura di DBMS e l'applicazione ha bisogno di adattarsi a questo. Per esempio nelle aree governative olandesi, Oracle è stata davvero forte, ma SQL Server ha stabilito una base di utenti abbastanza pure.

Quindi è necessario riflettere su quali combinazioni di DBMS che si desidera supportare, non solo in termini di funzionalità, ma anche in termini di costo.

Se attenersi a un DBMS, allora non ha senso andare a fare uno strato di accesso ai dati generico come BDE, DBX o ADO: si paga a fare un collegamento più diretto possibile. La mia esperienza mi ha insegnato che queste combinazioni funzionano bene:

Spero che questo ti dà una certa comprensione nelle possibilità ei limiti di supporto di più DBMS dalle applicazioni Delphi.

- Jeroen

Regola generale: ogni strato di componenti sarà eventualmente aggiungere un ulteriore livello di bug. Sia ADO e DBX sono involucri di componenti in tutto funzionalità database standard, quindi sono entrambi ugualmente forti. Quindi la scelta corretta dovrebbe essere basata su altri fattori, come i database che si desidera utilizzare. Se si desidera connettersi a MS-Access o SQL Server, ADO sarebbe la scelta migliore in quanto è più nativo per questi database. Ma Firebird e Oracle sono più nativo per i componenti DBX.

Io personalmente tendo ad usare l'API ADO cruda, però. Poi di nuovo, io non uso i componenti data-aware nei miei progetti. E 'meno RAD, lo so. Ma ho spesso bisogno di lavorare in questo modo perché io di solito scrivo applicazioni client / server con diversi strati tra il database e l'interfaccia grafica, rendendo le cose più complicate.

I miei due centesimi:. DBX è significativamente più veloce (sia su Oracle e SQL), e significativamente più schizzinoso e più difficile da implementare

Se le prestazioni sono un fattore, mi piacerebbe andare con DBX. In caso contrario, mi basta usare ADO per semplicità.

Come altri hanno detto, DBX possono avere il bordo in termini di prestazioni grezzo in certi casi o in circostanze specifiche, ma ADO è la base per un numero molto maggiore di applicazioni nel mondo così anche se le prestazioni di ADO può essere relativamente più poveri, in modo chiaro questo non significa che "inaccettabile" povero.

Per quanto mi riguarda, e informato da grandi progetti ho lavorato, il più grande "problema" con DBX è che non importa quanto buona possa essere, si tratta di una tecnologia di infrastruttura a chiave fornito da una società di lingua / strumenti.

Chiunque che ha costruito le applicazioni sulla tecnologia BDE precedente verrà testimoniare i disagi causati quando che la tecnologia è deprecato e non è più supportato. Mentre nessuna tecnologia è immune da deprecazione da esso del provider, ADO ha chiaramente il bordo quando si tratta di sostenere l'industria al di là del fornitore di tecnologia stessi.

Per questo motivo io stesso ora utilizzare sempre ADO. Basta cambiare la stringa di connessione non è sempre l'unica cosa di cui preoccuparsi quando si passa da un tipo di database a un altro però. sintassi di chiamata di stored procedure possono variare da un fornitore di ADO a un altro, e si devono ancora vedere la sintassi SQL si utilizza se si intende la distribuzione contro diversi motori SQL differenti, in cui il supporto SQL può variare da a un altro.

Per mitigare questi problemi che uso la mia incapsulamento del modello di oggetti ADO. Questo incapsulamento non tenta di mutare il modello a oggetti in qualcosa che non assomiglia ADO, espone semplicemente quelle parti di ADO che ho bisogno di utilizzare direttamente in una forma più ObjectPascal gentile (e "tipo" di sicurezza) (ad esempio, enum e tipi set per le costanti e le bandiere ecc, piuttosto che i punteggi se non centinaia di costanti intere).

Il mio incapsulamento si occupa anche di alcune delle piccole variazioni nei diversi comportamenti provider / requisiti, come ad esempio le differenze precedentemente citati nella sintassi chiamata di stored procedure.

Devo dire anche che simile ad un altro manifesto, ho troppo tempo fa smesso usato "Dati controlli consapevoli", che si apre questo approccio. Se hai necessità o desiderio di utilizzare i dati di controllo consapevole e si desidera utilizzare ADO, quindi non è possibile utilizzare ADO direttamente e deve invece trovare un po 'di incapsulamento che espone ADO attraverso il modello di set di dati VCL.

ADO è Microsoft mondo

DBX è stato creato agli inizi (Delphi 6) per il cross-platform e Kylix

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top