¿Cuánta compatibilidad tienen los motores DB en el nivel SQL?

Question

Digamos que quería tener una aplicación que pudiera cambiar fácilmente la base de datos en el back-end.
Estoy pensando principalmente en SQL Server como el back-end primario, pero con la flexibilidad de utilizar otro motor de base de datos. Firebird y PostGreSQL parecen tener (de mi breve excursión en Wikipedia) lo más común con el servidor SQL (además son gratuitos).

¿Qué tan similar sería la configuración de la base de datos, el acceso, las consultas, etc. para Firebird, PostGreSQL y MS SQL Server?

Answer 1

Trabajé en un proyecto donde era un requisito absoluto admitir muchas bases de datos, incluyendo al menos Access, SQL Server y Oracle.

Entonces sé que se puede hacer. La mayoría de DML (SELECCIONAR, ACTUALIZAR, INSERTAR ...) es igual y ciertamente no tuvimos grandes problemas para que funcione en todas las bases de datos, solo molestias ocasionales. MySQL era la excepción en ese momento, ya que simplemente no era lo suficientemente capaz.

Encontramos la mayoría de las diferencias en el DDL, pero con la arquitectura correcta (que teníamos), no fue difícil solucionarlo.

Lo único que nos causó un problema fue generar identificaciones únicas: el aumento automático no es estándar. Afortunadamente, en una base de datos de alrededor de 40 tablas, solo había unos pocos lugares donde se necesitaban ID únicos (buen diseño de base de datos). Al final, generamos la ID única en el código y manejamos cualquier conflicto (todo en las transacciones).

Facilitó las cosas porque habíamos evitado el uso de incremento automático para los campos de ID, es más difícil pensar en claves únicas, pero mejor a largo plazo.

Answer 2

Desafortunadamente, SQL varía ampliamente entre los proveedores. Es casi imposible escribir todo menos el SQL más trivial para ejecutarse en un número de RDBMS, y luego estás en el territorio de mínimo común denominador. Mucho mejor usar una capa de abstracción para manejar al menos la conexión a la base de datos (inc. Acceso, envío de consultas), y un ORM para manejar el propio SQL o el SQL por proveedor.

Si desea ver cómo varían, los buenos ejemplos son los identificadores de incremento automático y la obtención del ID del último registro insertado.

Answer 3

Bueno, las cosas CRUD deberían ser las mismas en todas partes, pero si construyes algo complejo, probablemente quieras usar disparadores y procedimientos almacenados y ahí es donde la compatibilidad se vuelve baja. Escribir una aplicación independiente de DBMS generalmente significa mover la mayor parte de la lógica de negocios fuera de la base de datos, por lo que tener una aplicación de 3 niveles es, en mi humilde opinión, una necesidad en tal caso.

Alternativamente, podría usar alguna biblioteca de contenedor que funcione como una capa de abstracción, pero aún no he visto una que pueda hacer el trabajo correctamente en un rango de DBMS-es. Por supuesto, eso también depende del lenguaje de programación que uses.

Answer 4

Como se señala en las otras respuestas, los DBMS varían enormemente una vez que va más allá de las cosas básicas de SELECCIONAR / INSERTAR (y a veces incluso allí).

También tenemos que mantener la compatibilidad entre varios DBMS. En mi opinión, el mejor enfoque suele ser utilizar algún tipo de capa de compatibilidad. Tenemos una biblioteca interna de abstracción de DB, pero hay varias herramientas disponibles.

En particular, podría pagar ver ORM populares (Hibernate, nHibernate, etc.). Por lo general, ofrecen independencia de DB como una especie de efecto secundario. Al menos Hibernate también tiene un lenguaje de consulta especial que se traducirá automáticamente a SQL para el DBMS que está utilizando.