¿Cuán necesario o conveniente es escribir SQL portátil?

Question

Una y otra vez, he visto a personas aquí y en todas partes abogando por evitar las extensiones no portables al lenguaje SQL, siendo this el último ejemplo. Solo recuerdo un artículo que dice lo que voy a decir, y ya no tengo ese enlace.

¿Realmente se ha beneficiado al escribir SQL portátil y descartar las herramientas/sintaxis patentadas de su dialecto?

Nunca he visto un caso de alguien que se tome el trabajo de construir una aplicación compleja en mysql y luego decir . ¿Sabes qué sería simplemente color de rosa? Cambiemos a (PostGreSQL | Oracle | SQL Server)!

Bibliotecas comunes en -say- PHP resumen las complejidades de SQL, pero ¿a qué costo? Usted termina siendo incapaz de usar construcciones y funciones eficientes, para un presunto brillo de portabilidad que probablemente nunca use. Esto me suena a los libros de texto YAGNI.

EDIT: Tal vez el ejemplo que he mencionado es demasiado mordaz, pero creo que el punto se mantiene: si usted está planeando un traslado de un DBMS a otro, es probable que el rediseño de la aplicación de todas formas, o no estarías haciéndolo en absoluto.

Answer 1

Los proveedores de software que trabajan con grandes empresas pueden no tener otra opción (de hecho, ese es mi mundo): sus clientes pueden tener políticas de usar solo productos de un proveedor de bases de datos. Perder los principales clientes es comercialmente difícil.

Cuando trabajas en dentro de una empresa, es posible que puedas beneficiarte del conocimiento de la plataforma.

En general, la capa de DB debe estar bien encapsulada, por lo que incluso si tuviera que realizar un puerto a una nueva base de datos, el cambio no debería ser generalizado. Creo que es razonable adoptar un enfoque YAGNI para portar a menos que tenga un requisito específico para el soporte inmediato de múltiples proveedores. Haga que funcione con su base de datos de destino actual, pero estructure el código cuidadosamente para permitir la futura portabilidad.

Answer 2

En la gran mayoría de las aplicaciones, apostaría a que hay poco o ningún beneficio e incluso un efecto negativo de intentar escribir sql portátil; sin embargo, en algunos casos hay un caso de uso real. Supongamos que está creando una aplicación web de seguimiento de tiempo. Y le gustaría ofrecer una solución autohospedada.

En este caso, sus clientes necesitarán tener un servidor de base de datos. Tienes algunas opciones aquí. Podría obligarlos a utilizar una versión específica que podría limitar su base de clientes. Si puede admitir múltiples DBMS, entonces tiene un cliente potencial más amplio que puede usar su aplicación web.

Answer 3

• Si eres corporativa, a continuación, utilizar la plataforma se le da
• Si usted es un vendedor, usted tiene que planificar para múltiples plataformas

longevidad de la empresa:

• Probablemente reescriba el código de cliente antes de migrar DBMS
• El DBMS probablemente sobrevivirá a su código de cliente (Java o C# contra '80 mainframe Me)

Recuerde:

SQL dentro de una plataforma suele ser compatible con versiones anteriores, pero las bibliotecas de cliente no lo son. Está obligado a migrar si el sistema operativo no admite una biblioteca o entorno de seguridad anterior, o una arquitectura de controlador, o biblioteca de 16 bits, etc.

Supongamos que tiene una aplicación en SQL Server 6.5. Todavía se ejecuta con algunos ajustes en SQL Server 2008. Apuesto a que no está utilizando el código de cliente sano ...

Answer 4

El problema con las extensiones es que debe actualizarlas cuando esté actualizando el sistema de la base de datos . Los desarrolladores a menudo piensan que su código durará para siempre, pero la mayoría del código deberá ser reescrito dentro de 5 a 10 años. Las bases de datos tienden a sobrevivir más tiempo que la mayoría de las aplicaciones, ya que los administradores son lo suficientemente inteligentes como para no arreglar las cosas que no están rotas, por lo que a menudo no actualizan sus sistemas con cada nueva versión.
Aún así, es un verdadero problema cuando actualiza su base de datos a una versión más nueva, pero las extensiones no son compatibles con esa y por lo tanto no funcionarán. Hace que la actualización sea mucho más compleja y exige que se reescriba más código.
Cuando elige un sistema de base de datos, a menudo se queda estancado con esa decisión durante años.
Cuando eliges una base de datos y algunas extensiones, ¡estás atascado con esa decisión durante mucho, mucho más tiempo!

Answer 5

El único caso donde puedo ver que es necesario es cuando está creando un software que el cliente comprará y usará en sus propios sistemas. Con mucho, la mayoría de la programación no cae en esta categoría. Rechazar el uso de un código específico del proveedor es garantizar que usted tenga una base de datos pormenorizada ya que el código específico del proveedor generalmente se escribe para mejorar el rendimiento de ciertas tareas con ANSII Standard SQL y se escribe para aprovechar la arquitectura específica de esa base de datos. He trabajado con bases de datos durante más de 30 años y nunca antes había visto una empresa cambiar su base de datos back-end sin una reescritura completa de la aplicación también. Evitar el código específico del proveedor en este caso significa que estás perjudicando tu rendimiento sin ningún motivo la mayor parte del tiempo.

También he usado muchos productos comerciales diferentes con bases de datos a través de los años. Sin excepción, cada uno de ellos fue escrito para soportar múltiples backends y, sin excepción, cada uno de ellos era un perro miserable y lento de un programa que realmente usaba a diario.

Answer 6

Siempre existen algunos beneficios y algunos costos al usar el dialecto "de mínimo común denominador" de un idioma para salvaguardar la portabilidad. Creo que los peligros del bloqueo de un determinado DBMS son bajos, en comparación con los peligros similares para la programación de languges, bibliotecas de objetos y funciones, escritores de informes, etc.

Esto es lo que recomendaría como la forma principal de salvaguardar la portabilidad futura. Haga un modelo lógico del esquema que incluya tablas, columnas, restricciones y dominios. Haga esto como DBMS independiente como sea posible, dentro del contexto de las bases de datos SQL.De lo único que dependerá el dialecto es el tipo de datos y el tamaño de algunos dominios. Algunos dialectos antiguos carecen de soporte de dominio, pero de todos modos debe hacer su modelo lógico en términos de dominios. El hecho de que dos columnas se extraigan del mismo dominio, y no solo compartan un tipo de datos y tamaño comunes, es de crucial importancia en el modelado lógico.

Si no entiende la distinción entre modelado lógico y modelado físico, apúntelo.

Haga que la mayor cantidad posible de estructura de índice sea portátil. Si bien cada DBMS tiene sus propias características de índice especiales, la relación entre índices, tablas y columnas es casi independiente de DBMS.

En términos de procesamiento de SQL CRUD dentro de la aplicación, utilice construcciones específicas de DBMS siempre que sea necesario, pero intente mantenerlas documentadas. Como ejemplo, no dudo en utilizar la construcción de Oracle "CONNECT BY" cada vez que creo que me servirá de algo. Si su modelado lógico ha sido independiente de DBMS, gran parte de su SQL CRUD también será independiente de DBMS incluso sin mucho esfuerzo de su parte.

Cuando llega el momento de moverse, espera algunos obstáculos, pero espera superarlos de manera sistemática.

(La palabra "que" en lo anterior es a quien corresponda, y no a la OP en particular.)