•  19-09-2019
  •  | 
  •  

Pregunta

¿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)

?

Tanto le permiten conectarse a las principales bases de datos. Me gusta la forma de ADO lo hace todo con un cambio de cadena de conexión y el hecho de que ADO y los controladores se incluyen con Windows para que nada extra para desplegar (al parecer, corríjanme si me equivoco).

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

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

Pero lo que es más fácil de programar, tiene un mejor rendimiento, utiliza la memoria más eficiente? Cualesquiera otras cosas para diferenciarlos de?

Gracias, Richard

¿Fue útil?

Solución

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 en 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 conductores con su solicitud si usted compra las fuentes de los conductores.

Otros consejos

En el comienzo de Delphi, la gente alabó el apoyo de múltiples DBMS en Delphi. Todo el mundo le encantó el BDE (porque era la única manera de hacerlo).

Sin embargo, cuando se mira en clientes a través de más de la última década, he visto una disminución constante de soporte multi-DBMS en sus aplicaciones.

El costo de soportar múltiples DBMS de una aplicación es alta.

No sólo porque usted tiene que tener conocimiento de cada DBMS, sino también porque cada DBMS tiene su propio conjunto de peculiaridades, donde se tiene que adaptar a la capa de acceso a datos. Estos incluyen no sólo las diferencias en la sintaxis y los tipos de datos subyacentes, sino también estrategias de optimización.

Además, algunos DBMS funcionan mejor con ADO, algunos mejor con una conexión directa (como saltar a su cliente de Oracle todos juntos).

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

He estado involucrado en algunos proyectos donde tuvimos que cambiar el backend SGBD y / o la tecnología de acceso de datos (es decir, del BDE a DBX, o de DBX a una conexión directa). Cambiar el backend siempre fue mucho más doloroso que el cambio de la tecnología de acceso a datos. enfoques de múltiples niveles les hizo un poco más fácil, pero aumentaron los grados de libertad y por lo tanto los esfuerzos de prueba.

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

Así que hay que pensar en lo que las combinaciones de DBMS quieres apoyar, no sólo en términos de funcionalidad, sino también en términos de costo.

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

Espero que esto te da una idea de las posibilidades y limitaciones de soportar múltiples DBMS de sus aplicaciones Delphi.

- Jeroen

Regla general: todas las capas de componentes, posiblemente, añadir una capa adicional de insectos. Tanto ADO y DBX son envoltorios componentes alrededor funcionalidad de base de datos estándar, por lo que ambos son igualmente fuertes. Así que la elección adecuada 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 nativa de estas bases de datos. Pero Firebird y Oracle son más nativo para los componentes DBX.

Yo personalmente tiendo a usar la API de ADO en bruto, sin embargo. Por otra parte, yo no uso componentes de datos en mis proyectos. Es menos RAD, lo sé. Sin embargo, a menudo necesito trabajar de esta manera porque generalmente escribo aplicaciones cliente / servidor con varias capas entre la base de datos y la interfaz gráfica de usuario, por lo tanto hacer las cosas más complicadas.

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, yo sólo tiene que utilizar ADO para simplificar.

Como han dicho otros, DBX pueden tener la ventaja en el rendimiento bruto en ciertos casos o en circunstancias específicas, pero ADO es la base para un número muy grande de aplicaciones en el mundo por lo que aunque el rendimiento de ADO puede ser relativamente más pobres, claramente eso no quiere decir "inaceptable" pobre.

En cuanto a mí, e informado por los principales proyectos que he trabajado, el mayor "problema" con DBX es que no importa lo bueno que sea, se trata de una tecnología de infraestructura de clave proporcionada por una empresa lenguaje / herramientas.

Cualquier persona que construye aplicaciones en la tecnología BDE anterior dará testimonio de las perturbaciones causadas cuando esa tecnología es obsoleto y ya no se admite. Mientras que ninguna tecnología es inmune a la desaprobación por ella del proveedor, ADO tiene claramente una ventaja cuando se trata de apoyo de la industria más allá del proveedor de tecnología de sí mismos.

Por eso yo ahora siempre uso de ADO. Simplemente cambiar la cadena de conexión no es siempre la única cosa que preocuparse cuando cambie de un tipo de base de datos a otro sin embargo. la sintaxis de llamada de procedimiento almacenado puede variar de un proveedor a otro ADO, y usted todavía tiene que ver la sintaxis SQL se utiliza si pretende desplegar contra múltiples motores SQL diferentes, donde el soporte de SQL puede variar de a otro.

Para mitigar estos problemas que utilizo mi propia encapsulación del modelo de objetos ADO. Esta encapsulación no trata de mutar el modelo de objetos en algo que no se parece ADO, simplemente expone aquellas partes de ADO que necesito para usar directamente en una forma más ObjectPascal amable (y "tipo" seguro) (por ejemplo, tipos de enumeración y conjuntos para las constantes y banderas, etc., en lugar de las puntuaciones si no cientos de constantes enteras).

Mi encapsulación también se ocupa de algunas de las variaciones menores en diferentes comportamientos del proveedor / requisitos, tales como las diferencias mencionadas anteriormente en la sintaxis de llamada de procedimiento almacenado.

Debería decir también que al igual que otro cartel, yo hace mucho tiempo dejé de datos usado "consciente" de los controles, lo que abre este enfoque. Si necesita o desea utilizar los datos de los controles conscientes y desea utilizar ADO, entonces no se puede utilizar ADO directamente y en su lugar debe encontrar algo de encapsulación que expone ADO a través del modelo de conjunto de datos VCL.

ADO es el mundo de Microsoft

DBX fue creado al principio (Delphi 6) para la plataforma de cruz y Kylix

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top