ADO ou DBX en utilisant Delphi

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

  •  19-09-2019
  •  | 
  •  

Question

Quel est le meilleur (et pour quelles raisons) à utiliser pour se connecter à MS SQL, Oracle ou Firebird à partir d'une application Win32 Delphi - ADO ou DBX (base de données Express)

?

Les deux vous permettent de vous connecter aux bases de données principales. J'aime la façon dont ADO fait tout avec un changement de chaîne de connexion et le fait que ADO et les pilotes sont inclus avec Windows donc rien de plus à déployer (il semble, me corriger si je me trompe).

DBX est également flexible et je peux compiler les pilotes dans mon application, je peux pas?

Je suis vraiment envie d'avoir une source unique, si possible, avec la possibilité de varier les bases de données en fonction de service / préférences informatiques du client.

Mais ce qui est plus facile à programmer, fonctionne mieux, utilise la mémoire la plus efficace? Toutes les autres pour les différencier sur?

Merci, Richard

Était-ce utile?

La solution

ADO est simple à utiliser et est là, vous ne devez assurez-vous d'installer le pilote client correponding du côté client.

J'ai trouvé DBX plus souple et il est mieux intégré dans l'IDE et une autre des technologies telles que DataSnap.

Dans le même but que vous, j'ai utilisé DBX avec les pilotes tiers de DevArt . Vous pouvez compiler les pilotes avec votre application si vous achetez les sources pilotes.

Autres conseils

Au début de Delphes, les gens louaient le support multi-SGBD en Delphi. Tout le monde aimait le BDE (parce que c'était la seule façon de le faire).

Mais quand on regarde les clients sur plus de la dernière décennie, je l'ai vu une diminution constante de la prise en charge multi-SGBD dans leurs applications.

Le coût du support SGBD multiples à partir d'une application est élevée.

Non seulement parce que vous devez avoir une connaissance de chaque SGBD, mais aussi parce que chaque SGBD a son propre ensemble de, où vous particularités devez adapter dans votre couche d'accès aux données. Ceux-ci comprennent non seulement des différences dans la syntaxe et les types de données sous-jacentes, mais aussi des stratégies d'optimisation.

En outre, certains SGBD fonctionnent mieux avec ADO, certains mieux avec une connexion directe (comme sauter tous ensemble votre client Oracle).

Enfin tester toutes les combinaisons de votre logiciel avec plusieurs systèmes de SGBD est très intense.

Je suis impliqué dans quelques projets où nous avons dû changer le backend SGBD et / ou la technologie d'accès aux données (de savoir BDE à DBX, ou de DBX à une connexion directe). Modification du back-end a toujours été beaucoup plus douloureux que de changer la technologie d'accès aux données. Les approches multi-niveaux les fait un peu plus facile, mais il a augmenté les degrés de liberté et à cet effet les efforts de test.

Certains des produits que je ne vois que le soutien multi-SGBD sont dans des applications verticales du marché où le client final a déjà leur propre infrastructure de SGBD et l'application doit adapter. Par exemple, dans les zones gouvernementales néerlandaises, Oracle a été très forte, mais SQL Server a mis en place et un bon nombre d'utilisateurs.

Vous devez penser à ce que les combinaisons de SGBD vous voulez soutenir, non seulement en termes de fonctionnalités, mais aussi en termes de coût.

Si vous vous en tenez à un SGBD, il n'a pas de sens d'aller pour une couche d'accès aux données générique comme BDE, DBX ou ADO: elle est payante faire une connexion aussi directe que possible. Mon expérience m'a appris que ces combinaisons fonctionnent bien:

Espérons que cela vous donne un aperçu des possibilités et des limites de soutien SGBD multiples de vos applications Delphi.

- jeroen

Règle générale: toutes les couches de composants sera peut-être ajouter une couche supplémentaire de bugs. ADO et DBX enveloppent composants autour des fonctionnalités de base de données standard, donc ils sont tous les deux aussi forte. Donc, le bon choix devrait se fonder sur d'autres facteurs, comme les bases de données que vous souhaitez utiliser. Si vous voulez vous connecter à MS-Access ou SQL Server, ADO serait le meilleur choix car il est plus natif pour ces bases de données. Mais Firebird et Oracle sont plus natif pour les composants DBX.

Je tends personnellement à utiliser l'API première ADO de, cependant. Là encore, je ne l'utilise composants de données dans mes projets. Il est moins RAD, je sais. Mais je dois souvent travailler de cette façon parce que j'écris généralement des applications client / serveur avec plusieurs couches entre la base de données et l'interface graphique, rendant ainsi les choses plus compliquées.

Mes deux cents:. DBX est nettement plus rapide (sur Oracle et SQL), et beaucoup plus pointilleux et plus difficiles à déployer

Si la performance est un facteur, je partirais avec DBX. Sinon, je venais d'utiliser ADO pour des raisons de simplicité.

Comme d'autres l'ont dit, DBX peut avoir l'avantage dans les performances brutes dans certains cas, ou dans des circonstances particulières, mais ADO est la base d'un nombre très grand d'applications dans le monde si bien que la performance de ADO peut être relativement plus pauvres, clairement cela ne signifie pas « inacceptable » pauvres.

Pour ma part, et éclairé par les grands projets auxquels j'ai travaillé, le plus grand « problème » avec DBX est que peu importe à quel point il peut être, il est une technologie d'infrastructure à clé fournie par une langue / société d'outils.

Toute personne qui a construit des applications sur la technologie précédente BDE témoignera de la perturbation causée lorsque cette technologie est obsolète et ne plus pris en charge. Bien qu'aucune technologie est à l'abri de dévalorisation par ce fournisseur de, ADO a clairement le bord en matière de soutien de l'industrie au-delà du fournisseur de technologies elles-mêmes.

Pour cette raison, moi-même je l'utilise maintenant toujours ADO. Il suffit de changer la chaîne de connexion n'est pas toujours la seule chose à se soucier lors du passage d'un type de base de données à l'autre cependant. syntaxe d'appel de procédure stockée peut varier d'un fournisseur ADO à l'autre, et vous avez encore de regarder la syntaxe SQL que vous utilisez si vous souhaitez déployer contre plusieurs différents moteurs SQL, où le support de SQL peut varier d'une à l'autre.

Pour atténuer ces problèmes que j'utiliser mon propre encapsulation du modèle d'objet ADO. Cette encapsulation ne tente pas de muter le modèle d'objet en quelque chose qui ne ressemble pas à ADO, il expose simplement les parties d'ADO que je dois utiliser directement sous une forme plus respectueuse ObjectPascal (et « type » de sécurité) (par exemple les types ENUM et jeux pour les constantes et les drapeaux, etc., plutôt que des scores, voire des centaines de constantes entières).

Mon encapsulation prend également soin de quelques-unes des variations mineures dans les différents comportements des fournisseurs / exigences, telles que les différences mentionnées précédemment dans la syntaxe d'appel de procédure stockée.

Je dois dire aussi que semblable à une autre affiche, moi aussi il y a longtemps cessé utilisé « données » contrôles au courant, qui ouvre cette approche. Si vous avez besoin ou souhaitez utiliser les contrôles orientés données et souhaitez utiliser ADO, vous ne pouvez pas utiliser ADO directement et doit trouver une place d'encapsulation qui expose ADO à travers le modèle de jeu de données VCL.

ADO est monde Microsoft

DBX a été créé au début (Delphi 6) pour la plate-forme transversale et Kylix

Non affilié à StackOverflow
scroll top