Mejores prácticas para maximizar la portabilidad en SQL Server 2016

8

Cuando se trata de desarrollar el prototipo de una solución, a menudo las tecnologías aún no se han decidido y podrían no ser las mismas que se utilizarán en el producto terminado.

En estos escenarios, tiendo a usar Microsoft SQL Server escribiendo las consultas de la manera más estándar posible para simplificar la migración eventual a otro servidor.

¿Existe alguna forma o práctica conocida para imponer el uso del SQL estándar sobre el dialecto T-SQL directamente en SQL Server o mediante SQL Server Management Studio (SSMS)?

— s.demuro
fuente

3

La portabilidad es un buen objetivo de libro de texto, pero rara vez ocurre en la práctica. Cuando puede elegir entre sintaxis estándar ( <>) y no estándar ( !=), donde no hay compromiso en el rendimiento o la mantenibilidad, siempre elijo estándar. Pero cuando se trata de otros costos, o no hay un equivalente estándar, aprovecho y me dedico. Las cosas que abandonas solo por la posibilidad de cambiar por completo las plataformas al por mayor simplemente no valen la pena.

— Aaron Bertrand

66

El único momento en que la portabilidad es un objetivo realista es cuando está escribiendo una aplicación que necesita integrarse con múltiples plataformas simultáneamente porque sus clientes usan plataformas diferentes. Incluso entonces, a menos que desee que la funcionalidad sea limitada y el rendimiento sea terrible en todas las plataformas, enviaría paquetes destinados a aprovechar las características de las plataformas individuales.

— Aaron Bertrand

1

Sólo curioso; En la historia de todos los tiempos, ¿ha cambiado personalmente el sistema de base de datos que una aplicación estaba usando por otro de grado equivalente (por ejemplo, Oracle -> SQLS)? No lo he hecho

— Caius Jard

2

La otra cosa que tenía curiosidad; ¿Cuánto de su prototipo sobrevive razonablemente para ser un sistema completo de grado de producción? La mayoría de mis prototipos casi no comparten aspectos con los sistemas completos que se escriben después de que el prototipo haya probado un concepto y haya emitido algunos enfoques razonables sobre cómo debería verse una solución; ¿Estás haciendo tus prototipos demasiado perfectos / aferrándolos demasiado tiempo?

— Caius Jard

16

El usuario Aaron Bertrand hizo algunos comentarios que se alinean bien con mis pensamientos sobre su pregunta. Esto es más un desafío de marco que una respuesta a su pregunta específica, pero creo que es valioso considerarlo en este contexto.

La portabilidad es un buen objetivo de libro de texto, pero rara vez ocurre en la práctica.

Si tiene que cambiar las plataformas en algún momento, no habrá cambios necesarios para la aplicación, la base de datos, y probablemente muchas otras cosas. Si puede ser algo "agnóstico de plataforma" sin demasiado esfuerzo, está bien. Pero es realmente una mala decisión comercial usar eso como un objetivo de diseño.

Hay muchos lugares en línea donde la gente discute las desventajas o la programación de esta manera, aquí hay uno de ellos que me parece bastante convincente:

¡Las capas de abstracción de bases de datos deben morir!

La falacia de la portabilidad

El autor usa un argumento que escucho todo el tiempo: si usa una buena capa de abstracción, será fácil pasar de $ this_database a $ other_database en el futuro.

Eso es una mierda. Nunca es fácil

En cualquier aplicación respaldada por bases de datos no triviales, nadie piensa en cambiar las bases de datos como un asunto fácil. Pensar que "la conversión será indolora" es una fantasía.

Los buenos ingenieros intentan seleccionar las mejores herramientas para el trabajo y luego hacen todo lo posible para aprovechar las características únicas y más potentes de su herramienta. En el mundo de las bases de datos, eso significa sugerencias específicas, indexación, tipos de datos e incluso decisiones de estructura de tabla. Si realmente se limita al subconjunto de características que es común en todos los RDBMS principales, está perjudicando enormemente a usted y a sus clientes.

Eso no es diferente de decir "Estoy haciendo para limitarme al subconjunto de PHP que es lo mismo en Perl y C, porque quizás quiera cambiar idiomas algún día y portar mi código 'sin problemas'".

Eso simplemente no sucede.

El costo de cambiar las bases de datos después de que una aplicación se desarrolle e implemente es bastante alto. Tiene posibles cambios de esquema e índice, cambios de sintaxis, trabajos de optimización y ajuste para rehacer, sugerencias para ajustar o eliminar, etc. Cambiar mysql_foo () a oracle_foo () es realmente el menor de sus problemas. Tocará la mayoría de sus SQL, si no todos, o al menos deberá verificarlo.

Eso no me suena "indoloro".

— Josh Darnell
fuente

11

No imponga STD SQL.

Primero decida qué DBMS utilizará de acuerdo con las necesidades de su proyecto, y aprovéchelo.

— McNets
fuente

9

Realmente no.

Existe SET FIPS_FLAGGER 'FULL'.

Esto imprime una advertencia para SQL no estándar, pero algunas advertencias son

No estoy seguro de qué estándar específico usa esto (y sospecho que puede ser SQL 92)
Desde una prueba rápida, esto no se queja del uso del +operador para la concatenación de cadenas o funciones propietarias, GETDATE()por lo que no parece muy completo.

— Martin Smith
fuente

3

"a menudo las tecnologías aún no se han decidido"

Yo diría que este NO es el caso en mi experiencia. De hecho, no creo haber oído hablar de esto, excepto por algo muy pequeño.

Por lo general, esto se establece y se espera que la nueva solución utilice lo que ya está en uso.

Estoy de acuerdo con los comentaristas anteriores en que, incluso si no está establecido, debe establecerlo primero antes de comenzar a escribir consultas y otro código. De lo contrario, simplemente te estás permitiendo un gran esfuerzo desperdiciado en una reescritura desde el principio.

— Marbry Hardin
fuente