¿Qué tan necesario o conveniente es escribir SQL portátil?

Question

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

¿Se ha beneficiado realmente de escribir SQL portátil y descartar las herramientas / sintaxis patentadas de su dialecto?

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

Las bibliotecas comunes en -say- PHP resumen las complejidades de SQL, pero ¿a qué costo? Termina incapaz de usar construcciones y funciones eficientes, para un presunto atisbo de portabilidad que probablemente nunca usará. Esto me suena a libro de texto YAGNI.

EDITAR: Tal vez el ejemplo que mencioné es demasiado sarcástico, pero creo que el punto sigue siendo: si está planeando un cambio de un DBMS a otro, es probable que esté rediseñando la aplicación de todos modos, o usted no lo estaría haciendo en absoluto.

Answer 1

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

Cuando trabajas dentro de una empresa, puedes beneficiarte del conocimiento de la plataforma.

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

Answer 2

El problema con las extensiones es que necesita actualizarlas cuando está actualizando el sistema de base de datos. Los desarrolladores a menudo piensan que su código durará para siempre, pero la mayoría del código deberá reescribirse 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 cosas que no están rotas, por lo que a menudo no actualizan sus sistemas con cada nueva versión. 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 atrapado con esa decisión durante años.
Cuando elige una base de datos y algunas extensiones, ¡Estás atrapado con esa decisión por mucho, mucho más tiempo!

Answer 3

El único caso en el que puedo verlo necesario es cuando está creando software que el cliente comprará y usará en sus propios sistemas. Con mucho, la mayoría de la programación no entra en esta categoría. Rehusarse a usar el código específico del proveedor es asegurarse de tener una base de datos con un rendimiento óptimo, ya que el código específico del proveedor generalmente está escrito para mejorar el rendimiento de ciertas tareas sobre ANSII Standard SQL y está escrito 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 he visto a una empresa cambiar su base de datos back-end sin una reescritura completa de la aplicación. Evitar el código específico del proveedor en este caso significa que está perjudicando su rendimiento sin razón alguna la mayor parte del tiempo.

También he utilizado 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 admitir múltiples backends y, sin excepción, cada uno de ellos era un perro miserable y lento de un programa para usar realmente a diario.

Answer 4

En la gran mayoría de las aplicaciones apostarí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 de alojamiento propio.

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

Answer 5

• Si eres corporativo, entonces usas la plataforma que te dan
• Si usted es un proveedor, debe planificar múltiples plataformas

Longevidad para empresas:

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

Recuerda:

SQL dentro de una plataforma suele ser compatible con versiones anteriores, pero las bibliotecas de cliente no lo son. Se ve obligado a migrar si el sistema operativo no puede admitir una biblioteca antigua, un entorno de seguridad, una arquitectura de controlador o una biblioteca de 16 bits, etc.

Entonces, suponga que tenía 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 cuerdo ...

Answer 6

Siempre hay algunos beneficios y algunos costos por usar el "mínimo común denominador" dialecto de un idioma para salvaguardar la portabilidad. Creo que los peligros de encerrarse en un DBMS en particular son bajos, en comparación con los peligros similares para programar languideces, bibliotecas de objetos y funciones, redactores de informes y similares.

Esto es lo que recomendaría como la forma principal de proteger la portabilidad futura. Haga un modelo lógico del esquema que incluya tablas, columnas, restricciones y dominios. Haga esto lo más independiente posible de DBMS, dentro del contexto de las bases de datos SQL. Lo único que dependerá del 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 y tamaño de datos comunes es de crucial importancia en el modelado lógico.

Si no comprende la distinción entre modelado lógico y modelado físico, aprenda.

Aproveche al máximo la estructura de índice como sea posible. Si bien cada DBMS tiene sus propias características especiales de índice, la relación entre índices, tablas y columnas es casi independiente de DBMS.

En términos de procesamiento CRUD SQL dentro de la aplicación, use construcciones específicas de DBMS cuando sea necesario, pero trate de mantenerlas documentadas. Como ejemplo, no dudo en usar Oracle '' CONNECT BY '' construir cada vez que creo que me hará algo bueno. Si su modelado lógico ha sido independiente de DBMS, gran parte de su CRUD SQL también será independiente de DBMS incluso sin mucho esfuerzo de su parte.

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

(La palabra `` usted '' en lo anterior es a quien corresponda, y no al OP en particular).