• Introduction
• Quelles sont les options qui pourraient être utilisées pour le travail de développement ?
• Que veulent les développeurs ?
• Combien les éditions sont différentes
• Le choix affecte-t-il les outils utilisés ?
• LocalDB
  • Avantages de LocalDb pour le développement
  • Négatifs de LocalDb pour le développement
• Quelles sont les autres éditions existantes ?
  • Express Edition
  • Developer Edition
  • Web, Standard, et Enterprise Editions
  • Azure SQL Database
• Version conteneurisée de toute édition
• Conclusion

Introduction

En tant que développeur, j’ai besoin d’une base de données SQL Server contre laquelle je peux développer et tester du code. Il existe plusieurs options parmi lesquelles choisir, et divers problèmes que vous pourriez avoir à prendre en compte. Dans cet article, nous allons examiner les choix et les décisions que vous devez prendre. L’édition LocalDb de SQL Server a été créée pour être l’édition évidente pour les développeurs ; Cette idée a-t-elle un sens pratique et quels avantages alternatifs présentent les autres éditions pour les développeurs ?

Le travail de développement nécessitera généralement un certain nombre d’instances de serveur. Celles-ci doivent-elles être partagées sur un seul serveur, ou réparties sur un certain nombre de serveurs ou de machines virtuelles ? Tous les serveurs de développement doivent-ils être de la même édition ? Est-il judicieux de s’appuyer sur une connexion Internet pour baser tous vos serveurs de développement dans le cloud, ou y a-t-il une place pour le traditionnel ” SQL Server sur l’ordinateur portable “.

Avant SQL Server 2005, il n’était pas difficile de choisir l’édition avec laquelle vous alliez développer. En dehors du produit lui-même, il y avait juste une édition gratuite pour les développeurs. Cela s’est ensuite compliqué, et continue de le faire, avec quelques permutations intéressantes à venir pour les développeurs avec l’introduction des conteneurs dans Windows 2016 et SQL Server 2016.

Quelles sont les options qui pourraient être utilisées pour le travail de développement ?

Couramment, il y en a :

• Express Edition
• Developer Edition
• Web Edition
• Standard Edition
• Enterprise Edition
• LocalDb
• Azure. base de données + Amazon RDS
• Version conteneurisée de toute édition

Il existe également une édition appelée Compact Edition qui a été dépréciée mais qui est toujours disponible. Elle présente certaines similitudes avec SQL Server, mais son encombrement est très faible et elle s’exécute en cours de processus. Compact Edition exécute un dialecte SQL, mais ce n’est pas une édition de SQL Server. Ce n’est vraiment pas une instance de développement appropriée pour développer et tester le code qui sera déployé sur SQL Server.

Que veulent les développeurs ?

1. Productivité
   Je suis le plus productif en tant que développeur de base de données lorsque j’ai ma propre instance sur ma propre machine que je peux arrêter, démarrer, déposer et créer à volonté. Lorsque la base de données ou l’instance est sur un serveur partagé, alors je trouve que le développement est plus lent – soit d’autres personnes modifient des choses sur lesquelles je travaille, soit elles font d’autres choses pour interrompre, ce qui devrait être, un cycle rapide de développement, déploiement et test.
2. Simplicité
   Un développeur devrait être libre de passer son temps à écrire, tester et déboguer du code et tout temps passé à gérer des ressources comme les bases de données SQL Server signifie qu’il a moins de temps pour faire les choses qui sont réellement utiles, et fournir de la valeur à l’entreprise.
3. Précision
   Dans un monde idéal, chaque développeur aurait une réplique rapide, locale et exacte de la production avec des données qui sont aussi proches que possible des données de production. Grâce à cela, ils peuvent tester que leurs modifications se comporteront de la même manière en production que dans leur environnement de développement. Il doit y avoir d’innombrables applications qui fonctionnent super rapidement sur une machine de développement mais qui sont plus lentes lorsqu’elles sont déployées dans une architecture 3 tiers avec beaucoup de latence et d’appels réseau entre les services. Il est également important de vérifier que le code que vous écrivez pour une base de données fonctionnera réellement sur une autre base de données. Si vous aviez SQL Server 2008 R2 en production, il n’y aurait aucun intérêt à développer avec SQL 2016 en utilisant des tables en mémoire.

Combien les éditions diffèrent-elles ?

Lorsque l’on développe et teste une application de base de données, il est souvent important de savoir que, lorsque l’on écrit du code et que l’on peut voir comment il agit en développement, on obtiendra un comportement similaire en production. Les éditions sont définies par les fonctionnalités qui sont installées et activées ; le code du moteur de base est le même que vous utilisiez l’une des éditions gratuites ou l’édition entreprise. Le problème se pose lorsque vous utilisez, par exemple, une fonctionnalité réservée aux entreprises dans le développement, mais que vous n’avez qu’une instance de l’édition standard dans la production. La comparaison complète de ces éditions est publiée par Microsoft ici ‘Fonctionnalités prises en charge par les éditions de SQL Server 2016’

Le choix affecte-t-il les outils utilisés ?

Toutes les instances se comportent de la même manière en termes de moteur central et de langage ; si, par conséquent, vous avez un outil qui peut gérer l’édition Enterprise, alors il peut, en principe, également gérer toutes les autres éditions. Par le passé, tous les outils n’ont pas respecté ce principe : il existait autrefois une version de SQL Management Studio pour SQL Express qui était limitée et ne pouvait pas gérer les fonctionnalités de l’édition complète. Désormais, SQL Server Management Studio est rétrocompatible avec les versions précédentes et latéralement compatible avec toutes les éditions. Il est actuellement disponible en téléchargement gratuit afin que vous puissiez gérer n’importe quelle instance sans avoir besoin d’une licence complète.

La deuxième limitation est que, pour utiliser LocalDb, vous devez modifier la bibliothèque client SQL et donc les anciennes versions de SQLOLEDB et de .Net ne peuvent pas se connecter – si vous avez une application qui a été écrite en .net qui est antérieure à la version 4 alors elle peut ne pas se connecter.

Quel choix d’éditions avons-nous pour développer sur ?

LocalDb

Sauf si vous avez une exigence spécifique que LocalDb ne peut pas satisfaire, alors il doit être le premier choix pour les développeurs. Regardons ce qu’il est et ensuite quels avantages il offre.

LocalDb est une version réduite de SQL Server qui a été spécifiquement conçue pour être légère et facile à démarrer et arrêter rapidement. Cela signifie un compromis donc il y a quelques restrictions pour cela, mais c’est vraiment un excellent choix pour la plupart des développeurs car vous pouvez rapidement créer, utiliser et détruire des instances qui sont spécifiques à un utilisateur particulier.

LocalDb a quelques avantages supplémentaires : Il partage les mêmes binaires pour chaque instance, de sorte que vous n’avez pas besoin d’utiliser beaucoup d’espace disque pour chaque instance dont vous avez besoin. Cela signifie qu’il est vraiment simple d’en démarrer une si vous trouvez que vous avez besoin d’une nouvelle instance dans le feu d’une session de développement.

Créer un nouveau LocalDb est simple : Il suffit de taper ce qui suit au shell de commande :

Cela va créer une nouvelle instance que vous pouvez utiliser appelée “nom de l’instance”, sur ma machine, il faut environ 4 secondes pour créer une nouvelle instance, puis environ 2 secondes supplémentaires pour démarrer l’instance. L’installation d’une nouvelle instance de l’un des autres types de SQL Server se mesure en minutes ou en heures.

Si vous avez plusieurs versions de LocalDb installées, vous pouvez créer n’importe laquelle de ces versions vraiment facilement, juste en exécutant ce code dans un shell de commande :

Vous obtiendrez une liste comme :

Alors, si vous avez besoin d’une instance 2012, vous taperez :

Vous obtenez alors une nouvelle instance de SQL Server 2012 à laquelle vous pouvez vous connecter.

La connexion à LocalDb est un peu différente de la connexion à une instance standard : Au lieu de se connecter au nom de la machine et de passer soit un port, soit un nom d’instance, vous passez le mot “(localdb)” et ensuite le nom de l’instance, donc si l’instance s’appelle “test-instance”, vous passeriez ceci comme nom de votre serveur :

Pour savoir quelles instances vous avez, vous pouvez utiliser :

Cela va lister les instances LocalDb, pour en examiner une autre passez le nom de l’instance à la dernière commande telle que :

La sortie sera sera

• le nom
• version
• à quel utilisateur il appartient
• s’il a été démarré ou non
• l’heure du dernier démarrage

S’il est démarré, il donne également le chemin du tube nommé sur lequel il est exécuté. Si vous avez un client qui ne comprend pas le nom de serveur (localdb), alors peut-être que vous pouvez vous connecter sur des tuyaux nommés à l’instance.

LocalDb est génial pour le développement contre parce qu’il est si rapide de créer et de démarrer des instances, si vous travaillez souvent sur différents projets, vous pouvez arrêter et démarrer des instances et avoir beaucoup d’instances différentes disponibles sans la surcharge de devoir les maintenir et les stocker sur le disque. Elles présentent évidemment les mêmes inconvénients que les Express, dans la mesure où il s’agit de versions réduites de SQL Server. Il n’y a, par exemple, pas d’indexation plein texte, ce qui peut les empêcher de pouvoir être utilisées dans certaines applications.

Avantages de LocalDb pour le développement :

• Développement rapide, il est simple de créer de nouvelles instances pour le développement et les tests.
• Partage des binaires entre toutes les instances de la même version, ce qui évite de prendre beaucoup d’espace disque ou de devoir maintenir de nombreuses versions différentes

Négatifs de LocalDb pour le développement :

• Ne comprend pas certaines fonctionnalités fondamentales telles que SQL Agent
• ne supporte pas FILESTREAM
• ne peut pas être un abonné de réplication de fusion,
• ne permet que des files d’attente locales pour Service Broker.
• toujours s’exécute sous le contexte de sécurité des utilisateurs;

Quelles sont les autres éditions existantes?

Express Edition

L’édition Express est une version gratuite de SQL Server qui est destinée aux petites bases de données avec un faible nombre d’utilisateurs. Dans la version 2016, Express est limitée à quatre cœurs, 1 Go de ram par instance et une taille maximale de base de données de 10 Go. Bien qu’il s’agisse d’une taille raisonnable, elle n’est pas assez grande pour la plupart des applications de base de données de production, mais elle est utile pour le travail de développement si votre instance de développement ne nécessite pas beaucoup de ressources et est petite, et si vous ne développez aucune fonctionnalité qui dépend des fonctionnalités Standard ou Entreprise uniquement..

Avantages d’Express pour le développement :

• Les problèmes de performance apparaîtront plus nettement en développement
• Il n’y a pas de complications de licence pour le travail de développement
• Il convient au développement individuel et partagé.
• Les services réseau peuvent être configurés comme avec les éditions complètes, ainsi vous pouvez vous connecter avec tcp depuis des machines distantes et peuvent être utilisés par le service SQL Browser pour autoriser les connexions en utilisant le nom d’instance
• Il peut être téléchargé et installé librement

Négatifs d’Express pour le développement :

• Ne comprend pas l’ensemble des fonctionnalités de l’une des versions de production
• Requiert une installation standard complète pour créer une nouvelle instance, cela prend du temps à installer et à mettre à niveau et pas mal d’espace disque par instance
• Ne doit pas être utilisé pour les tests de charge ou de performance

Developer Edition

Developer edition est une édition Enterprise entièrement fonctionnelle de SQL Server dont toutes les limitations ont été supprimées. C’est génial si vous développez une application qui utilise l’édition Enterprise, mais si vous développez une application qui utilise l’édition Standard, alors vous pouvez trouver que vous obtenez de meilleures performances que vous le feriez en production ou vous finissez par utiliser une fonctionnalité qui est réservée à l’entreprise. Cela peut être une erreur coûteuse de développer du code, pour découvrir qu’il ne peut pas être exécuté lorsque vous le déployez.

Si vous travaillez sur une seule application de base de données et que vous allez déployer sur un serveur existant qui utilise l’édition Enterprise, alors vous ne pouvez pas vous tromper beaucoup si vous utilisez l’édition de développement de SQL Server.

La licence pour SQL Server 2000 signifiait que l’édition de développement était gratuite tant que l’utilisation était pour le développement et les tests plutôt que comme base de données de production. Si vous aviez décidé d’utiliser l’édition développeur pour la production, alors elle aurait été tarifée comme l’édition entreprise. Lors de la sortie de SQL 2005, une modification de la licence a entraîné le paiement d’un petit montant de 50 dollars par développeur pour pouvoir utiliser l’édition développeur. Cela signifie que de nombreuses personnes n’ont pas pu utiliser la version de développement, en particulier dans les équipes où les développeurs n’utilisaient SQL que rarement ou qui n’avaient pas d’abonnement MSDN fournissant aux développeurs une licence pour l’édition de développement. Cela était particulièrement notable dans les équipes non .net qui se trouvaient utiliser SQL Server.

Selon le guide de licence de SQL Server 2016, “SQL Server Developer Edition ne peut pas être utilisé dans un environnement de production ou avec des données de produit” – en supposant que “données de produit” signifie “données de production” alors il semble qu’il n’est pas possible de sauvegarder et de restaurer une base de données de production pour tester contre à moins que vous obteniez une licence pour le serveur comme un serveur de production. Le guide indique également que l’édition développeur peut être utilisée gratuitement si vous rejoignez le programme “Dev Essentials” – si vous avez besoin d’une édition différente telle que Enterprise ou Standard pour développer/tester contre, alors vous pouvez y accéder en utilisant un abonnement “Visual Studio”.

Avantages de l’édition Developer pour le développement:

• L’édition Developer est une édition Enterprise à part entière, donc si vous effectuez des tests et que cela fonctionne sur Developer, alors le code devrait se comporter de la même manière que votre serveur Enterprise de production.

Négatifs de l’édition Developer pour le développement:

• Uniquement approprié pour développer une base de données pour l’édition Enterprise. Parce que certaines fonctionnalités et certains comportements de l’édition Developer sont absents de l’édition Web ou Standard, votre système de production aura moins de fonctionnalités que votre environnement de développement, ce qui n’est jamais une bonne idée.
• Il utilise pas mal d’espace disque par instance
• La licence n’est pas claire, donc nécessite une vérification avec votre représentant de licence Microsoft

Éditions Web, Standard et Enterprise

Ces versions nécessitent toutes une licence pour être utilisées en production. Vous ne pouvez acheter l’édition web que par l’intermédiaire de fournisseurs d’hébergement d’applications. Il est souvent plus sûr de développer contre l’édition de SQL Server que vous allez déployer, certainement pour tout test de performance ou d’évolutivité, sinon pour le développement de tous les jours. Comme discuté avec l’édition Development, la licence est un peu floue et vous pouvez potentiellement avoir à payer une licence pour utiliser l’une de ces éditions dans un environnement de dev ou de test.

L’édition web n’est pas généralement disponible et vous devez normalement acheter des licences pour elle par le biais d’un fournisseur d’hébergement, ce qui ajoute un peu de complexité supplémentaire.

Avantages des éditions de production pour le développement:

• Vous développerez et testerez dans un environnement similaire à la production, ce qui est presque toujours une bonne chose pour les développeurs.

Négatifs des éditions de production pour le développement:

• Requiert une installation standard complète pour créer une nouvelle instance : Cela prend du temps à installer et à mettre à niveau, et pas mal d’espace disque par instance
• La licence n’est pas claire et nécessite de vérifier avec votre représentant de licence Microsoft

Azure SQL Database

Utiliser des fournisseurs de cloud pour héberger des bases de données pour vous peut avoir un réel sens lors du développement et des tests, mais ils ont quelques inconvénients. En dehors du prix que vous devez payer pour les utiliser, vous devez également comprendre que la latence entre votre machine et la base de données sera généralement beaucoup plus élevée qu’une instance locale ou même locale LAN. Vous aurez également besoin d’une connexion persistante à la base de données, de sorte que les trajets du soir terminant une pièce de travail dans le train sont peu probables.

L’utilisation de ceux-ci pour un travail de développement pur où vous déployez constamment des changements et exécutez des scripts n’est probablement pas idéale, mais ils peuvent vraiment s’imposer pour les tests, en particulier dans le cadre de suites de tests automatisés qui s’exécutent dans des fournisseurs hébergés tels que Appveyor ou VSTS.

Avoir la possibilité de créer une nouvelle instance, de déployer votre code et d’exécuter vos tests est formidable pour un processus d’intégration continue (ci) afin que vous puissiez exécuter plusieurs builds simultanément sans avoir soit à maintenir une instance ou une base de données spécifique pour chaque build – une fois que vous avez passé le cap d’avoir un seul build dans le cadre de votre processus ci, cette approche simple pour déployer des bases de données aide vraiment.

Avantages d’Azure SQL Database pour le développement:

• Simplicité dans la mise en place de nouvelles bases de données, d’autant plus que cela peut être automatisé
• Pas de maintenance de vos instances de développement donc pas de patch, pas de sauvegardes etc.

Négatifs d’Azure SQL Database pour le développement :

• Plus adapté aux tests qu’au développement car une connexion persistante est nécessaire et sera plus lente que le développement local
• Vous devez payer par minute d’utilisation de la base de données

Version conteneurisée de n’importe quelle édition

Windows 2016 et SQL Server 2016 ont tous deux un support pour exécuter SQL Server dans un conteneur. Cela nous donne toute la flexibilité dont nous bénéficions avec LocalDb et Azure+AWS pour démarrer et arrêter les instances rapidement. Nous devrions également voir les avantages de ne pas avoir à patcher chaque instance individuellement tant que nous utilisons des images communes pour nos instances.

Windows 2016 est maintenant sorti, donc nous pouvons potentiellement créer et jeter des instances de SQL Server (certainement SQL Server 2016) assez simplement si nous avons Windows 10 ou Windows 2016. Si nous sommes liés à une version antérieure de Windows ou à une version de SQL Server, alors il pourrait ne pas être aussi simple de créer une image qui fonctionne.

Une fois que nous aurons une adoption généralisée des conteneurs dans Windows, cela devrait signifier que nous pouvons créer de nouvelles instances et démarrer et arrêter des instances sans le long processus d’installation. À ce stade, il semble qu’il sera plus lent de démarrer et d’arrêter des instances que ce n’est le cas avec LocalDb.

Si vous testez vos bases de données dans un environnement de type cloud tel que le service Microsoft VSTS, vous pouvez également constater que le démarrage d’une instance LocalDb est faisable car elle est déjà installée. En revanche, le téléchargement de l’image de la base de données SQL Server 2016, puis son démarrage, pourrait prendre trop de vos minutes de construction.

Conclusion

Lorsque nous développons du code pour les bases de données SQL Server, nous, en tant que développeurs, avons trois exigences principales :

• nous voulons être productifs aussi rapidement que possible;
• nous voulons que notre environnement soit aussi simple que possible;
• nous ne voulons pas particulièrement dépendre d’une bonne connectivité internet ;
• nous voulons utiliser une version de test qui simule le monde réel d’un point de vue fonctionnel (pas nécessairement les performances pour le développement au jour le jour)

LocalDb est généralement la réponse pour la plupart des développeurs SQL Server et, à moins que vous ayez une exigence spécifique qui signifie que vous ne pouvez pas l’utiliser, je le recommande fortement.