Desarrollando aplicaciones cross-DB

7

Hasta ahora siempre he codificado usando SQL dialéctico sin formato / incrustado. Esto me parece obviamente incorrecto porque lo relaciona con tecnologías concretas, por lo que su software no se puede implementar en ninguna máquina, especialmente en los servidores.

En general (independientemente del lenguaje de programación y RDBMS), ¿qué opciones tiene uno en este caso? ¿Qué tan buenos son cada uno de ellos? ¿Cuál dirías que es el enfoque estándar?

    
pregunta vemv 26.07.2011 - 14:35

6 respuestas

11

En general, lo que debería hacer es abstraer el código de su base de datos en su propia capa (ensamblado, dll o lo que sea).

En el código de la aplicación, usted llama a la interfaz que "detrás de escena" determina qué código de base de datos necesita y llama a que para hacer el trabajo. Dependiendo de cómo esté configurada su aplicación, esto podría ser algo decidido en el momento de la compilación, el tiempo de instalación o el tiempo de ejecución.

Una tecnología clave para buscar es Inversion of Control o Inyección de dependencia . Esto le permitirá ejercer este control sobre su aplicación y decidir qué versión del código necesita.

    
respondido por el ChrisF 26.07.2011 - 14:41
10

Francamente, como persona de la base de datos, el código más eficiente que puede escribir es usar el fragmento de código específico para su base de datos. En mis 30 años de trabajo con bases de datos, nunca hemos cambiado el backend de base de datos para una aplicación y las únicas situaciones en las que parece necesario son cuando comienza con una mala elección (como Access cuando necesita una base de datos grande) o si vende el software Commercial-off-the-Shelf (COTS) que necesita soportar cualquier backend que el cliente tenga. Sacrificar el rendimiento hoy en día con la idea de que algún día es posible que necesite cambiar los backends no es una buena manera de hacerlo. Hay mucho más para cambiar el backend de una base de datos después de que tenga muchos registros que solo cambiar el código de la aplicación y el dba inteligente prefiere no correr el riesgo.

    
respondido por el HLGEM 26.07.2011 - 15:33
6

ORM. enlace

Funciona realmente, muy bien para divorciar una aplicación de SQL.

    
respondido por el S.Lott 26.07.2011 - 14:45
2

(Esta respuesta tiene que ver con las declaraciones SQL en sí mismas, y no con la forma en que se implementan).

No creo que lo llame estándar, pero el enfoque más común que he visto es usar el subconjunto de "denominador común más bajo" de las características de SQL que admiten todas las plataformas de destino. Por ejemplo, si una de sus plataformas de destino no admite expresiones de tabla comunes, nunca use expresiones de tabla comunes.

Ese enfoque intercambia cierta flexibilidad de SQL y cierto rendimiento para la flexibilidad de implementación.

Algunas variaciones de SQL se pueden enmascarar mediante sustitución de macros en el momento de la compilación. Una macro podría expandirse a una función DATE_ADD() en una plataforma, y a un valor de fecha y hora + un valor de intervalo en otra. Esto puede hacer que se acerque más al rendimiento óptimo en todas las plataformas de destino para un subconjunto ligeramente mayor de funciones de lenguaje SQL, pero puede ser un verdadero dolor mantenerlo.

El enfoque de fuerza bruta es mantener un conjunto de diferencias específicas de la plataforma para todas sus declaraciones SQL. Las declaraciones simples como SELECT * FROM TABLENAME se pueden compartir en todas las plataformas; Las declaraciones más complejas que aprovechan las características específicas de la plataforma o la sintaxis tienen versiones diferentes para cada plataforma. En mi experiencia, este enfoque requiere una gran cantidad de pruebas automatizadas para garantizar que todas las plataformas se comporten igual.

No he pensado mucho en eso, pero creo que cuanto más agnóstico de plataforma quieras ser, más probabilidades tendrás de terminar cerca del enfoque de fuerza bruta. ¿Qué tan difícil es eso? Bueno, los candidatos más probables son las herramientas CASE de base de datos y las utilidades de esquema de base de datos, y no hay muchos de ellos que se dirijan a más de un puñado de plataformas actuales. Calculo que es bastante difícil.

    
respondido por el Mike Sherrill 'Cat Recall' 26.07.2011 - 15:26
2

Otros han sugerido abstraer la capa de la base de datos, esto está bien, pero al final tendrá un código de base de datos diferente para diferentes plataformas de base de datos, especialmente si el código de la base de datos utiliza tecnologías de plataforma de base de datos específicas. Esto se puede mantener, pero si la aplicación tiene 400 tablas y 1000 procesos almacenados en Oracle y usted necesita portar ese servidor SQL, es una gran montaña para escalar.

Un enfoque alternativo es escribir una declaración SQL que se ejecutará en todas las plataformas de base de datos. El propio SQL está estandarizado (sq-89, sql-92, sql3), etc. Si todas las plataformas admiten sql-92, asegúrese de que los datos, las consultas y las actualizaciones utilicen el código compatible con sql-92. Luego, la capa de datos abstraídos ejecuta un conjunto de consultas, independientemente de la plataforma DB.

Si se realiza este enfoque, habrá que hacer algunos sacrificios y es posible que tenga más código de aplicación para admitir la capa de datos. Algunas bases de datos no admiten procedimientos almacenados, etc., pero el sql que se envía y se envía debe aceptarse universalmente, entonces es DB cruzado.

    
respondido por el Jon Raynor 26.07.2011 - 19:37
1

He trabajado en una aplicación grande que cambió las bases de datos (de SQL Server a MySQL). Hay mucho que aprendí en ese tiempo. Creo que si quieres desarrollar una aplicación de base de datos cruzada debes tener algunas cosas en mente. Primero, ten una lista de bases de datos soportadas No tendrá los recursos para desarrollar y probar contra todas las bases de datos. En segundo lugar, use un ORM que admita todas las bases de datos a las que se dirige, o (y esto podría ser preferible) atenerse al SQL básico que funciona en todas sus bases de datos específicas. Utilice solo SQL diferente para cada base de datos si tiene un problema de rendimiento. Dependiendo de la aplicación, puede llegar bastante lejos con las declaraciones "estándar" de selección, incorporación, inserción, actualización y eliminación.

    
respondido por el Kibbee 26.07.2011 - 19:56

Lea otras preguntas en las etiquetas