• Introducción
• ¿Qué opciones hay que se puedan utilizar para el trabajo de desarrollo?
• ¿Qué quieren los desarrolladores?
• ¿Qué diferencias hay entre las ediciones
• La elección afecta a las herramientas que se utilizan?
• LocalDB
  • Beneficios de LocalDb para el desarrollo
  • Negativos de LocalDb para el desarrollo
• ¿Qué otras ediciones hay?
  • Edición Express
  • Edición para desarrolladores
  • Edición Web, Standard, y Enterprise Editions
  • Azure SQL Database
• Versión en contenedor de cualquier edición
• Conclusión

Introducción

Como desarrollador, necesito una base de datos de SQL Server contra la que pueda desarrollar y probar código. Hay varias opciones para elegir, y varias cuestiones que podría tener que tener en cuenta. En este artículo veremos las opciones y las decisiones que debe tomar. La edición LocalDb de SQL Server fue creada para ser la edición obvia para los desarrolladores; ¿tiene esa idea sentido práctico y qué ventajas alternativas tienen las otras ediciones para los desarrolladores?

El trabajo de desarrollo normalmente requerirá varias instancias de servidor. ¿Deben ser compartidas en un servidor, o distribuidas en varios servidores o máquinas virtuales? ¿Deben ser todos los servidores de desarrollo de la misma edición? ¿Es prudente depender de una conexión a Internet para basar todos sus servidores de desarrollo en la nube, o hay un lugar para el tradicional ‘SQL Server en el portátil’.

Antes de SQL Server 2005, no era difícil elegir la edición que se utilizaría para desarrollar. Aparte del producto en sí, sólo había una edición gratuita para desarrolladores. Luego se complicó, y sigue haciéndolo, con algunas permutaciones interesantes que se avecinan para los desarrolladores con la introducción de los contenedores en Windows 2016 y SQL Server 2016.

¿Qué opciones hay que se puedan utilizar para el trabajo de desarrollo?

Actualmente las hay:

• Express Edition
• Developer Edition
• Web Edition
• Standard Edition
• Enterprise Edition
• LocalDb
• Azure base de datos + Amazon RDS
• Versión contenedorizada de cualquier edición

También existe una edición llamada Compact Edition que ha quedado obsoleta pero que aún está disponible. Tiene algunas similitudes con SQL Server pero tiene una huella muy pequeña y se ejecuta en proceso. Compact Edition ejecuta un dialecto de SQL, pero no es una edición de SQL Server. Realmente no es una instancia de desarrollo apropiada para desarrollar y probar código que se desplegará en SQL Server.

¿Qué quieren los desarrolladores?

1. Productividad
   Soy más productivo como desarrollador de bases de datos cuando tengo mi propia instancia en mi propia máquina que puedo detener, iniciar, soltar y crear a voluntad. Cuando la base de datos o la instancia está en un servidor compartido entonces encuentro que el desarrollo es más lento – o bien otras personas cambian cosas en las que estoy trabajando o hacen otras cosas para interrumpir, lo que debería ser, un rápido ciclo de desarrollo, despliegue y prueba.
2. Simplicidad
   Un desarrollador debe ser libre de pasar su tiempo escribiendo, probando y depurando el código y cualquier tiempo dedicado a la gestión de recursos como las bases de datos de SQL Server significa que tienen menos tiempo para hacer las cosas que son realmente útiles, y proporcionar valor a la empresa.
3. Precisión
   En un mundo ideal cada desarrollador tendría una réplica rápida, local y exacta de la producción con los datos que es lo más cercano posible a los datos de producción. Con esto, pueden probar que sus cambios se comportarán de la misma manera en producción que en su entorno de desarrollo. Debe haber innumerables aplicaciones que funcionan súper rápido en una máquina de desarrollador, pero que son más lentas cuando se despliegan en una arquitectura de 3 niveles con mucha latencia y llamadas de red entre los servicios. También es importante verificar que el código que se escribe para una base de datos se ejecute realmente en otra base de datos. Si tuvieras SQL Server 2008 R2 en producción, no tendría sentido desarrollar con SQL 2016 utilizando tablas en memoria.

¿Qué diferencias hay entre las ediciones?

Cuando desarrollamos y probamos una aplicación de base de datos, a menudo es importante saber que, cuando estamos escribiendo código y podemos ver cómo actúa en desarrollo, obtendremos un comportamiento similar en producción. Las ediciones se definen por las características que se instalan y habilitan; el código del motor central es el mismo tanto si se utiliza una de las ediciones gratuitas como la edición empresarial. El problema surge cuando se utiliza, por ejemplo, una función exclusiva para empresas en desarrollo, pero sólo se tiene una instancia de la edición estándar en producción. La comparación completa de estas ediciones la publica Microsoft aquí ‘Features Supported by the Editions of SQL Server 2016’

¿Afecta la elección a las herramientas que se utilizan?

Todas las instancias se comportan igual en cuanto al motor central y al lenguaje; si, por tanto, tienes una herramienta que puede gestionar la edición Enterprise entonces puede, en principio, gestionar también cualquier otra edición. No todas las herramientas del pasado respetaron este principio: hubo una vez una versión de SQL Management studio para SQL Express que se limitaba a no poder gestionar las características de la edición completa. Ahora SQL Server Management Studio es compatible con versiones anteriores y con todas las ediciones. Actualmente está disponible como una descarga gratuita para que pueda gestionar cualquier instancia sin requerir una licencia completa.

La segunda limitación es que, con el fin de utilizar LocalDb, es necesario cambiar la biblioteca de cliente de SQL y por lo que la versión más antigua de SQLOLEDB y .Net son incapaces de conectarse – si usted tiene una aplicación que fue escrito en .net que es anterior a la versión 4, entonces puede no conectarse.

¿Qué opción de ediciones tenemos para desarrollar?

LocalDb

A menos que tenga un requisito específico que LocalDb no puede cumplir, entonces debe ser la primera opción para los desarrolladores. Vamos a ver lo que es y luego los beneficios que ofrece.

LocalDb es una versión recortada de SQL Server que fue diseñado específicamente para ser ligero y fácil de iniciar y detener rápidamente. Esto significa un compromiso por lo que hay algunas restricciones para ello, pero realmente es una gran opción para la mayoría de los desarrolladores porque se pueden crear, utilizar y destruir rápidamente instancias que son específicas para un usuario en particular.

LocalDb tiene algunos beneficios adicionales: Comparte los mismos binarios para cada instancia, por lo que no tienes que utilizar mucho espacio en disco para cada instancia que necesites. Esto significa que es realmente sencillo arrancar uno si se encuentra que necesita una nueva instancia en el calor de una sesión de desarrollo.

Crear un nuevo LocalDb es sencillo: Sólo tienes que escribir lo siguiente en el shell de comandos:

Esto creará una nueva instancia que podrás utilizar llamada “nombre de instancia”, en mi máquina tarda unos 4 segundos en crear una nueva instancia y luego otros 2 segundos en iniciar la instancia. La instalación de una nueva instancia de cualquiera de los otros tipos de SQL Server se mide en minutos a horas.

Si tienes varias versiones de LocalDb instaladas, puedes crear cualquiera de esas versiones muy fácilmente, simplemente ejecutando este código en un shell de comandos:

Obtendrás una lista como:

Entonces si necesitas una instancia de 2012 escribirías:

Entonces obtendría una nueva instancia de SQL Server 2012 a la que podría conectarse.

La conexión a LocalDb es un poco diferente a la conexión a una instancia estándar: En lugar de conectarse al nombre de la máquina y pasar un puerto o un nombre de instancia, pasas la palabra “(localdb)” y luego el nombre de la instancia, así que si la instancia se llama “test-instance” pasarías esto como tu nombre de servidor:

Para saber qué instancias tienes puedes usar:

Esto listará las instancias de LocalDb, para examinar una más pasa el nombre de la instancia al último comando como:

La salida será será

• el nombre
• versión
• a qué usuario pertenece
• si se ha iniciado o no
• la última hora de inicio

Si se ha iniciado, también da la ruta de la tubería con nombre en la que se está ejecutando. Si usted tiene un cliente que no entiende el nombre del servidor (localdb) entonces tal vez usted puede conectarse a través de tuberías con nombre a la instancia.

LocalDb es grande para el desarrollo en contra porque es muy rápido para crear e iniciar las instancias, si usted trabaja a menudo en diferentes proyectos que puede detener e iniciar las instancias y tener un montón de diferentes instancias disponibles sin la sobrecarga de tener que mantenerlos y almacenarlos en el disco. Obviamente, tienen las mismas desventajas que Express, ya que son versiones reducidas de SQL Server. Por ejemplo, no hay indexación de texto completo, lo que puede impedir su uso en algunas aplicaciones.

Beneficios de LocalDb para el desarrollo:

• Desarrollo rápido, es sencillo crear nuevas instancias para el desarrollo y las pruebas.
• Comparte los binarios entre todas las instancias de la misma versión para no ocupar mucho espacio en disco ni tener que mantener muchas versiones diferentes

Negativos de LocalDb para desarrollo:

• No incluye algunas características fundamentales como SQL Agent
• no soporta FILESTREAM
• no puede ser un suscriptor de replicación merge,
• sólo permite colas locales para Service Broker.
• Siempre se ejecuta bajo el contexto de seguridad de los usuarios;

¿Qué otras ediciones hay?

Edición Express

La edición Express es una versión gratuita de SQL Server que está pensada para pequeñas bases de datos con un bajo número de usuarios. En la versión 2016 Express está limitada a cuatro núcleos, 1GB de ram por instancia y un tamaño máximo de base de datos de 10 GB. Aunque es un tamaño razonable, no es lo suficientemente grande para la mayoría de las aplicaciones de bases de datos de producción, pero es útil para el trabajo de desarrollo si su instancia de desarrollo no requiere muchos recursos y es pequeña, y si no está desarrollando ninguna funcionalidad que dependa de las características de Standard o Enterprise..

Beneficios de Express para el desarrollo:

• Los problemas de rendimiento aparecerán de forma más evidente en el desarrollo
• No hay complicaciones de licencia para el trabajo de desarrollo
• Es adecuado tanto para el desarrollo individual como para el compartido.
• Se pueden configurar los servicios de red igual que con las ediciones completas, por lo que se puede conectar con tcp desde máquinas remotas y puede ser utilizado por el servicio SQL Browser para permitir conexiones utilizando el nombre de la instancia
• Se puede descargar e instalar libremente

Negativos de Express para desarrollo:

• No incluye el conjunto completo de características de una de las versiones de producción
• Requiere una instalación estándar completa para crear una nueva instancia, esto lleva tiempo de instalación y actualización y bastante espacio en disco por instancia
• No debe usarse para pruebas de carga o rendimiento

Edición para desarrolladores

La edición para desarrolladores es una edición Enterprise completamente funcional de SQL Server que tiene todas las limitaciones eliminadas. Esto es genial si está desarrollando una aplicación que utiliza la edición Enterprise, pero si está desarrollando una aplicación que utiliza la edición Standard entonces puede encontrar que obtiene un mejor rendimiento que el que tendría en producción o termina utilizando una característica que es sólo para empresas. Puede ser un error costoso desarrollar código, sólo para descubrir que no se puede ejecutar cuando se despliega.

Si trabaja en una sola aplicación de base de datos y va a desplegar a un servidor existente que está utilizando la edición Enterprise, entonces no puede ir muy mal si utiliza la edición de desarrollo de SQL Server.

La licencia de SQL Server 2000 significaba que la edición de desarrollador era gratuita siempre y cuando el uso fuera para el desarrollo y las pruebas en lugar de como una base de datos de producción. Si se hubiera decidido utilizar la edición para desarrolladores para producción, entonces tendría el mismo precio que la edición para empresas. Cuando se lanzó SQL 2005, un cambio en las licencias supuso el pago de una pequeña cuota de 50 dólares por desarrollador para poder utilizar la edición para desarrolladores. Esto significaba que mucha gente no podía utilizar la versión de desarrollo, especialmente en los equipos en los que los desarrolladores sólo utilizaban SQL en contadas ocasiones o en los que no estaban suscritos a MSDN, que proporcionaba a los desarrolladores una licencia para la edición para desarrolladores. Esto fue especialmente notable en los equipos no .net que pasó a utilizar SQL Server.

De acuerdo con la guía de licencias de SQL Server 2016, “SQL Server Developer Edition no puede ser utilizado en un entorno de producción o con los datos del producto” – asumiendo “datos del producto” significa “datos de producción”, entonces parece que no es posible hacer una copia de seguridad y restaurar una base de datos de producción para probar contra a menos que usted licencia el servidor como un servidor de producción. La guía también indica que la edición para desarrolladores se puede utilizar de forma gratuita si te unes al programa “Dev Essentials” – si necesitas una edición diferente como Enterprise o Standard para desarrollar/probar, entonces puedes acceder a ellas usando una suscripción a “Visual Studio”.

Beneficios de la edición Developer para el desarrollo:

• La edición Developer es una edición Enterprise completa, por lo que si está probando y funciona en Developer, el código debería comportarse igual que su servidor Enterprise de producción.

Negativos de la edición Developer para el desarrollo:

• Sólo es apropiada para desarrollar una base de datos para la edición Enterprise. Debido a que algunas de las características y el comportamiento de la edición Developer faltan en Web o Standard Edition, su sistema de producción tendrá menos características que su entorno de desarrollo, lo que nunca es una buena idea.
• Utiliza bastante espacio en disco por instancia
• La licencia no está clara, por lo que requiere una comprobación con su representante de licencias de Microsoft

Las ediciones Web, Standard y Enterprise

Todas estas versiones requieren una licencia para ser utilizadas en producción. Sólo se puede comprar la edición web a través de proveedores de alojamiento de aplicaciones. A menudo es más seguro desarrollar contra la edición de SQL Server que va a desplegar, ciertamente para cualquier prueba de rendimiento o escalabilidad si no para el desarrollo diario. Como se ha comentado con la edición de Desarrollo, las licencias son un poco confusas y es posible que tenga que pagar por una licencia para utilizar una de estas ediciones en un entorno de desarrollo o de pruebas.

La edición web no está disponible de forma general y normalmente hay que comprar licencias para ella a través de un proveedor de alojamiento, lo que añade cierta complejidad adicional.

Beneficios de las ediciones de producción para el desarrollo:

• Estará desarrollando y probando en un entorno similar al de producción, lo que casi siempre es bueno para los desarrolladores.

Negativos de las ediciones de producción para el desarrollo:

• Requiere una instalación estándar completa para crear una nueva instancia: Esto lleva tiempo de instalación y actualización, y bastante espacio en disco por instancia
• Las licencias no están claras y requieren consultar con el representante de licencias de Microsoft

Azure SQL Database

Usar proveedores en la nube para alojar bases de datos para ti puede tener mucho sentido a la hora de desarrollar y hacer pruebas, pero tienen algunas desventajas. Aparte del precio que hay que pagar para utilizarlos, también hay que entender que la latencia entre su máquina y la base de datos será normalmente significativamente más alta que una instancia local o incluso LAN. También necesitará una conexión persistente a la base de datos, por lo que esos desplazamientos nocturnos para terminar un trabajo en el tren son poco probables.

Usar estos para el trabajo de desarrollo puro, donde usted está constantemente desplegando los cambios y la ejecución de secuencias de comandos, probablemente no es ideal, pero realmente puede venir en su propio para las pruebas, especialmente como parte de las suites de pruebas automatizadas que se ejecutan en los proveedores alojados como Appveyor o VSTS.

Tener la capacidad de crear una nueva instancia, desplegar su código y ejecutar sus pruebas es genial para un proceso de integración continua (ci) para que pueda ejecutar múltiples construcciones de forma concurrente sin tener que mantener una instancia o base de datos específica para cada construcción – una vez que pase a tener una sola construcción como parte de su proceso ci este enfoque simple para desplegar bases de datos realmente ayuda.

Beneficios de Azure SQL Database para el desarrollo:

• Simplicidad en la configuración de nuevas bases de datos, especialmente porque esto puede ser automatizado
• Sin mantenimiento de sus instancias de desarrollo por lo que no hay parches, ni copias de seguridad, etc.

Negativos de Azure SQL Database para el desarrollo:

• Más adecuado para las pruebas que para el desarrollo ya que se requiere una conexión persistente y será más lento que el desarrollo en local
• Hay que pagar por minuto de uso de la base de datos

Versión en contenedor de cualquier edición

Windows 2016 y SQL Server 2016 tienen soporte para ejecutar SQL Server en un contenedor. Th-s nos da toda la flexibilidad que obtenemos con LocalDb y Azure+AWS para iniciar y detener instancias rápidamente. También deberíamos ver los beneficios de no tener que parchear cada instancia individualmente siempre que utilicemos imágenes comunes para nuestras instancias.

Windows 2016 ya ha sido lanzado, por lo que ahora podemos potencialmente crear y tirar instancias de SQL Server (ciertamente SQL Server 2016) de forma bastante sencilla si tenemos Windows 10 o Windows 2016. Si estamos atados a una versión anterior de Windows o versión de SQL Server entonces puede que no sea tan sencillo crear una imagen que funcione.

Una vez que consigamos la adopción generalizada de contenedores en Windows debería significar que podemos crear nuevas instancias e iniciar y detener instancias sin el largo proceso de instalación. En este momento, parece que será más lento iniciar y detener instancias que en el caso de LocalDb.

Si pruebas tus bases de datos en un entorno similar a la nube, como el servicio VSTS de Microsoft, también puedes encontrar que iniciar una instancia de LocalDb es factible, ya que está instalada. Por el contrario, descargar la imagen de la base de datos de SQL Server 2016 y luego iniciarla podría ocupar demasiados de sus minutos de compilación.

Conclusión

Cuando desarrollamos código para bases de datos de SQL Server, los desarrolladores tenemos tres requisitos principales:

• queremos ser productivos lo más rápido posible;
• queremos que nuestro entorno sea lo más sencillo posible;
• no queremos especialmente depender de una buena conectividad a Internet;
• queremos utilizar una versión de prueba que simule el mundo real desde el punto de vista de la funcionalidad (no necesariamente del rendimiento para el desarrollo del día a día)

LocalDb suele ser la respuesta para la mayoría de los desarrolladores de SQL Server y, a menos que tenga un requisito específico que le impida utilizarlo, se lo recomiendo encarecidamente.