ADO o DBX usando Delphi

Question

¿Qué es mejor (y por qué razones) a utilizar para conectarse a MS SQL, Oracle o pájaro de fuego desde una aplicación de Delphi Win32 - ADO o DBX (base de datos Express)?

Ambos le permiten conectarse a las principales bases de datos. Me gusta la forma en que ADO lo hace todo con un cambio de cadena de conexión y el hecho de que ADO y los controladores están incluidos con Windows, así que no hay nada más que implementar (parece, corrígeme si estoy equivocado). También

DBX no es flexible y puede compilar los controladores en mi aplicación, ¿verdad?

Realmente estoy interesado en tener una sola fuente, si es posible, con la capacidad de variar en función de las bases de datos del departamento/preferencias de TI del cliente.

Pero lo que es más fácil de programar, tiene un mejor rendimiento, utiliza la memoria más eficiente? ¿Alguna otra cosa para diferenciarlos?

Gracias, Richard

Answer 1

ADO es fácil de usar y está ahí, sólo debe asegurarse de instalar el controlador de cliente correponding en el lado del cliente.

He encontrado DBX más flexible y está mejor integrado dentro de IDE y otras tecnologías como DataSnap.

Con el mismo objetivo que tú, he utilizado DBX con Terceros Los conductores de DevArt. Puede compilar los controladores con su aplicación si compra las fuentes de controladores.

Answer 2

Regla general: cada capa de componentes posiblemente agregará una capa adicional de errores. Tanto ADO como DBX son envoltorios de componentes en torno a la funcionalidad de base de datos estándar, por lo que ambos son igualmente sólidos. Por lo tanto, la elección correcta debe basarse en otros factores, como las bases de datos que desea utilizar. Si desea conectarse a MS-Access o SQL Server, ADO sería la mejor opción ya que es más nativo para estas bases de datos. Pero Firebird y Oracle son más nativos para los componentes de DBX.

Personalmente, suelo usar las API ADO sin formato. Por otra parte, no uso componentes que tengan en cuenta los datos en mis proyectos. Es menos RAD, lo sé. Pero a menudo necesito trabajar de esta manera porque generalmente escribo aplicaciones de cliente/servidor con varias capas entre la base de datos y la GUI, lo que complica aún más las cosas.

Answer 3

ADO es el mundo de Microsoft

DBX fue creado al principio (Delphi 6) de plataforma cruzada y Kylix

Answer 4

Mis dos centavos: DBX es significativamente más rápido (tanto en Oracle y SQL), y significativamente más meticuloso y más difícil de implementar.

Si el rendimiento es un factor, me gustaría ir con DBX. De lo contrario, solo usaría ADO por simplicidad.

Answer 5

Como han dicho otros, DBX puede tener la ventaja en el rendimiento crudo en ciertos casos o en circunstancias específicas, pero ADO es la base para un número mucho mayor de aplicaciones en el mundo, por lo que aunque el rendimiento de ADO puede ser relativamente inferior, claramente eso no significa "inaceptablemente" pobre.

Personalmente, e informado por los principales proyectos en los que he trabajado, el mayor "problema" con DBX es que no importa cuán buena sea, es una tecnología de infraestructura clave proporcionada por una compañía de herramientas/lenguaje.

Cualquiera que haya creado aplicaciones con la tecnología BDE anterior dará fe de la interrupción causada cuando esa tecnología está en desuso y ya no es compatible. Si bien ninguna tecnología es inmune a la depreciación por parte de su proveedor, ADO claramente tiene la ventaja cuando se trata del soporte de la industria más allá del propio proveedor de tecnología.

Por esa razón, yo mismo ahora siempre uso ADO. Sin embargo, cambiar la cadena de conexión no siempre es lo único de lo que preocuparse cuando se cambia de un tipo de base de datos a otro. La sintaxis de llamada de procedimiento almacenado puede variar de un proveedor ADO a otro, y aún debe observar la sintaxis SQL que utiliza si tiene la intención de implementar en varios motores SQL diferentes, donde el soporte SQL puede variar de uno a otro.

Para mitigar estos problemas, uso mi propia encapsulación del modelo de objetos ADO. Esta encapsulación no intenta mutar el modelo de objetos en algo que no se parezca a ADO, simplemente expone aquellas partes de ADO que necesito usar directamente en una forma más amigable para ObjectPascal (y "tipo" segura) (por ejemplo, tipos de enum y conjuntos para constantes y banderas, etc., en lugar de tan solo puntajes sino cientos de constantes enteras).

Mi encapsulación también se ocupa de algunas de las pequeñas variaciones en los diferentes comportamientos/requisitos del proveedor, como las diferencias mencionadas anteriormente en la sintaxis de las llamadas al procedimiento almacenado.

Debo decir también que, al igual que en otro póster, hace mucho tiempo que dejé de utilizar los "controles de datos conscientes", lo que abre este enfoque. Si necesita o desea utilizar controles que tengan en cuenta los datos y desea utilizar ADO, no puede usar ADO directamente y, en su lugar, debe encontrar alguna encapsulación que exponga ADO a través del modelo de conjunto de datos VCL.

Answer 6

Al principio de Delphi, la gente elogiaba el soporte multi-DBMS en Delphi. Todo el mundo amaba el BDE (porque esa era la única forma de hacerlo).

Pero al ver a los clientes más de la última década, he visto una disminución constante del soporte de múltiples DBMS en sus aplicaciones.

El costo de admitir múltiples DBMS desde una aplicación es alto.

No solo porque tiene que tener conocimiento de cada DBMS, sino también porque cada DBMS tiene su propio conjunto de peculiaridades, donde tiene que adaptarse en su capa de acceso a datos. Estos no solo incluyen diferencias en sintaxis y tipos de datos subyacentes, sino también estrategias de optimización.

Además, algunos DBMS funcionan mejor con ADO, algunos mejoran con una conexión directa (como omitir todos los clientes de Oracle).

Finalmente, probar todas las combinaciones de su software con múltiples sistemas DBMS es muy intenso.

He estado involucrado en algunos proyectos en los que tuvimos que cambiar el back-end DBMS y/o la tecnología de acceso a datos (desde, por ejemplo, BDE a DBX, o desde DBX a una conexión directa). Cambiar el back-end siempre fue mucho más doloroso que cambiar la tecnología de acceso a datos. Los enfoques multinivel los hicieron más fáciles, pero aumentaron los grados de libertad y, por lo tanto, los esfuerzos de prueba.

Algunos de los productos que veo compatibles con multi-DBMS se encuentran en aplicaciones de mercado vertical donde el cliente final ya tiene su propia infraestructura DBMS y la aplicación necesita adaptarse a eso. Por ejemplo, en áreas gubernamentales holandesas, Oracle ha sido muy fuerte, pero SQL Server también ha establecido una base de usuarios bastante grande.

Así que debe pensar qué combinaciones de DBMS desea admitir, no solo en términos de funcionalidad, sino también en términos de costo.

Si se apega a un DBMS, entonces no tiene sentido ir por una capa de acceso a datos genéricos como BDE, DBX o ADO: vale la pena hacer una conexión tan directa como sea posible. Mi experiencia me ha enseñado que estas combinaciones funcionan bien:

• Interbase o Firebird con FIBPlus, AnyDAC, IBO o IBX *
• Oracle con AnyDAC, DOA o ODAC

• Microsoft SQL Server con ADO

  • IBX no le gusta Fi Rebird mucho.

Hope esto le da una idea de las posibilidades y limitaciones de soportar múltiples DBMS de sus aplicaciones Delphi.

--jeroen