¿Cuán importante es la portabilidad de SQL?

Question

Me parece, a partir de la experiencia personal y las preguntas y respuestas de SO, que las implementaciones de SQL varían sustancialmente. Uno de los primeros problemas para las preguntas SQL es: ¿Qué dbms estás usando?

En la mayoría de los casos con SQL hay varias formas de estructurar una consulta determinada, incluso utilizando el mismo dialecto. Pero me parece interesante que la portabilidad relativa de varios enfoques no se discuta con frecuencia, ni se valora mucho cuando lo es.

Pero incluso sin tener en cuenta la posibilidad de que una aplicación determinada pueda o no estar sujeta a conversión, creo que preferiríamos que nuestras habilidades, hábitos y patrones fueran lo más portátiles posible.

En su trabajo con SQL, ¿con qué intensidad prefiere la sintaxis SQL estándar? ¿Cuán activamente evitas las variaciones de propiedad? Por favor, responda sin hacer referencia a las preferencias de propiedad con el fin de percibir un mejor desempeño, que la mayoría concedería es generalmente una defensa lo suficientemente legítima.

Answer 1

Nos lo tomamos muy en serio en nuestra tienda. No permitimos extensiones o SQL no estándar a menos que sean compatibles con TODAS las plataformas principales. Incluso entonces, están marcados dentro del código como no estándar y las justificaciones son necesarias.

No corresponde al desarrollador de la aplicación hacer que sus consultas se ejecuten rápidamente, tenemos una clara separación de tareas. La consulta solo debe ser optimizada por el propio DBMS o por el ajuste de los DBA del DBMS.

Las bases de datos reales, como DB2/z :-), procesan SQL estándar de forma rápida.

La razón por la que hacemos cumplir esto es para dar la opción del cliente. No les gusta la idea de estar encerrados en un proveedor específico más de lo que nosotros lo hacemos.

Answer 2

No hay una respuesta clara sobre si la portabilidad de SQL es deseable o no, realmente depende mucho de la situación, como el tipo de aplicación.

Si la aplicación va a ser un servicio, es decir, solo lo alojarás, obviamente nadie más te importará si tu SQL es lo suficientemente portátil, por lo que puedes ignorarlo mientras no tengas planes específicos para dejar de apoyar a su plataforma actual.

Si la aplicación va a instalarse en varios sitios, cada uno con sus propios sistemas de bases de datos establecidos, obviamente la portabilidad SQL es muy importante para las personas. Le permite ampliar su mercado potencial, y puede darles un poco de tranquilidad a los clientes que están en la cerca con respecto a su sistema de base de datos. Si usted quiere apoyar eso, o si está feliz vendiendo solo a, por ejemplo, clientes de Oracle, o solo a clientes de MySQL/PostgreSQL, por ejemplo, depende de usted y de lo que usted piense que es su mercado.

Si está codificando en PHP, la gran mayoría de sus clientes potenciales probablemente esperan MySQL. Si es así, no es gran cosa asumir MySQL. O de manera similar, si está en C# /. NET, podría asumir Microsoft SQL Server. De nuevo, sin embargo, existe una otra cara porque puede existir un mercado pequeño pero menos competitivo de usuarios de PHP o .NET que desean conectarse a otros sistemas de bases de datos de los habituales.

Así que en gran medida consideraría esto como una pregunta de investigación de mercado, a menos que en mi primer ejemplo proporcione un servicio alojado en el que no le importe a los usuarios, en cuyo caso es sólo para su propia conveniencia.

Answer 3

Yo voto en contra estándar/sql proveedor independiente

• Sólo rara vez la base de datos es en realidad conmutada.
• No hay una única base de datos que cumpla totalmente con el estándar sql actual. Entonces, incluso cuando usted está en conformidad estándar, no es independiente del proveedor.
• Las diferencias entre proveedores van más allá de la sintaxis sql. El comportamiento de bloqueo es diferente. Los niveles de aislamiento son diferentes.
• pruebas de base de datos es bastante difícil y poco desarrollado. No hay necesidad de hacerlo aún más difícil lanzando múltiples proveedores en el juego, si no lo necesitas absolutamente.
• hay mucha potencia en los ajustes específicos del proveedor.(Piensa 'límite', o 'funciones analíticas', o 'consejos')

Así la quintaesencia: - Si no hay ningún requisito para la independencia del proveedor, obtener especializado para el vendedor en realidad se está utilizando. - Si existe un requisito para la independencia del proveedor, asegúrese de que quién paga la factura, que esto costará dinero. Asegúrese de tener todos los rdbms disponibles para las pruebas. Y úsela también - Ponga cada pieza de sql en una capa especial, que es conectable, para que pueda usar la potencia de la base de datos Y trabajar con diferentes proveedores - Solo cuando la diferencia es una cuestión pura de sintaxis vaya con el estándar , p.ej usando la notación de Oracle para uniones (externas) vs la sintaxis estándar ANSI.

Answer 4

En mi experiencia, la portabilidad de consultas no es tan importante. Trabajamos con varias fuentes de datos (principalmente MSSQL y MySQL), pero sabemos qué datos se almacenan y dónde podemos optimizarlos en consecuencia. Dado que controlamos los sistemas, decidimos cuándo, si es que alguna vez, las estructuras se mueven y las consultas necesitan ser reescritas.

También me gusta usar ciertas otras funciones específicas del servidor, como la notificación de consultas en SQL Server, que MySQL no ofrece. Entonces, una vez más, la usamos cuando podemos y no nos preocupamos por la portabilidad.

Además, algunas partes de nuestras aplicaciones necesitan consultar la información del esquema y actuar en consecuencia. Aquí, una vez más, tenemos un código específico del servidor para los diferentes sistemas, en lugar de tratar de restringirnos al mínimo común denominador.