Para este artículo empezaremos comentando como es un entorno común de trabajo, que de encaje al ciclo de desarrollo de SW elegido en vuestra empresa. Luego veremos que nos ofrece MS SQL Server. Y al final os comento mi opinión.

Si nos paramos a pensar como son los entornos de trabajo de una empresa de desarrollo, muchos de vosotros encajaréis en en lo siguiente:

• 1 Entorno de desarrollo: Volumen de datos reducido, esquema igual que producción + nuevos cambios. AKA Desarrollo,
• [0..N] Entornos de pruebas de integración: Volumen de datos reducido, esquema igual al de producción. AKA Integración.
• [0..M] Entornos de pruebas de carga: Volumen de datos similar a Producción, esquema clon de producción, configuración (servidor e instancia) igual a producción. AKA Load Test
• [1..P] Entornos de producción: entorno final del producto/aplicación. AKA Producción.

Por [0..N], nos referimos a cero o más. [1..M]: Al menos uno, etc. Basta decir la importancia que tiene la consistencia entre entornos es crucial para que el ciclo de desarrollo del SW funcione correctamente.

Ejemplo 1: la definición de una tabla o el código de un procedimiento almacenado en Desarrollo debe ser igual al del resto de los entornos antes de un nuevo cambio.

Ejemplo 2: La configuración del entorno de Load Test debe ser un clon al de Producción, en todos los sentidos: Esquema de BD, configuración de la instancia de SQL Server, configuración del servidor, etc. De lo contrario las pruebas realizadas aquí no tendrán valor o muy poco, ya que no nos servirá para predecir el comportamiento de Producción en situaciones de alta carga de trabajo.

Ahora que hemos planteado el escenario, veamos que nos ofrece SQL Server para cada entorno, resumido en dos líneas:

• Entornos de no Producción: MSSQL Developer.
• Entornos de Producción: MSSQL Standard o Enterprise.

Standard tiene muchas características/opciones y Enterprise las tiene todas. Por citar un ejemplo: El motor de SQL Server en Enterprise, para una consulta X, usará automáticamente una vista indexada, en caso de que exista y ayude a generar un mejor plan de ejecución y por tanto optimize el rendimiento de la consulta. En Standard no es así. Por eso la diferencia de costes de licencias entre una y otra. Aquí puedes ver todas las diferencias entre las ediciones, hay un buen número.

Pos su parte la edición MSSQL Developer funciona con todas las opciones de Enterprise, seguramente con algún matiz pero ahora no entraremos en eso. Lo cual está muy bien para ver qué es lo que ofrece el MSSQL, probar y tratar de convencer a tus jefes de lo bueno que es Enterprise para que lo compren.

Pero… ¿Qué pasa si el entorno de Producción tiene que ser Standard, sí o sí? Developer edition no tiene hasta la fecha ninguna opción para configurarlo como otra edición diferente. WTF!!??

¡Sí amigos! Esto es lo que hay por ahora… pero se puede hacer algo para que lo cambien. Para ello existe un ticket abierto (Editado 1-Mayo-2020: enlace actualizado debido a cambio de sitio de MS para peticiones en SQL Server), si te interesa como a mí ¡Vota!

Hasta el próximo post!