Pourquoi devrais-je utiliser Visual Studio 2010 sur SSMS pour le développement de ma base de données?

Question

Visual Studio 2010 présente projets de base de données et toute une gamme de fonctionnalités connexes qui faciliteraient le développement de la base de données. J'ai utilisé SQL Server Management Studio (SSMS) pendant de nombreuses années pour faire mon développement de base de données sans problème.

Pourquoi devrais-je m'embêter avec VS2010 lorsque SSMS fonctionne pour moi? Que fait-il, en particulier, mieux que SSMS?
Mais peut-être que ma prémisse est incorrecte et SSMS l'emporte toujours sur VS pour le développement de la base de données. Si oui, de quelles manières spécifiques est-ce vrai?

ConcernedOfTunbridgeWells · Answer

En fait, j'étais un peu déçu par VS2010, pour être honnête. Je pense qu'il est plus facile de travailler avec un script de création de table à l'ancienne et des fichiers pour les procédures stockées. Si vous avez besoin d'une gestion de schéma, vous pouvez obtenir Redgate SQL Compare Pro pour quelques centaines de dollars.

Si vous avez vraiment besoin d'un outil de modélisation de base de données, Powerdesigner ou même Erwin fait un bien meilleur travail, bien qu'ils ne soient pas particulièrement bon marché.

Bien que je préfère SSMS, j'ai utilisé les deux. Quelques avantages et inconvénients:

SSMS a une interface utilisateur qui "fonctionne" bien pour le développement SQL. La construction et l'utilisation de scripts de création sont beaucoup plus pratiques que les cerceaux que VS2010 vous oblige à parcourir. Beaucoup, beaucoup plus flexible (+ SSMS).
VS2010 a une gestion de schéma de base (c'est-à-dire la génération de scripts de différence/patch) (+ VS2010). Cependant, ce n'est pas si bon et a quelques défauts. Par exemple, il correspond aux contraintes de nom. Si vous avez des contraintes de vérification ou par défaut sur une colonne sans les nommer, SQL Server génère un nom aléatoire dans les coulisses. Cela confondra VS2010 si vous installez le script sur une machine différente car les contraintes peuvent avoir des noms différents. Redgate est moins cher et meilleur. (+ VS2010, mais imparfait).
VS2010 est vraiment maladroit - vous devez avoir un fichier pour chaque table ou autre objet DB. Essentiellement, vous devez faire les choses à la manière de VS2010, ce qui est assez lourd. (- VS2010)
VS2010 est également quelque peu fragile et l'intégration du contrôle de source est fragile. Même sur une base de données simple, chaque table, contrainte, procédure stockée, index et autre objet de base de données est son propre fichier. Les fichiers sont ajoutés au projet tout le temps, beaucoup plus rapidement qu'un projet de programmation typique avec (disons) C #. Avec une concurrence optimiste, il a tendance à supprimer silencieusement les fichiers du projet lorsque les enregistrements se désynchronisent. Même avec une bonne discipline d'équipe, les commentaires de l'interface utilisateur sur le statut sont très médiocres. Ce serait un désastre sur un modèle complexe. (-VS2010 - Je considérerais presque que c'est une faille spectaculaire pour un grand projet).
SSMS est livré avec SQL Server - ne peut pas battre le prix (+ SSMS).
VS2010 n'a toujours pas de référentiel approprié comme (par exemple) PowerAMC ou Oracle Designer. Vous ne pouvez pas facilement interroger le modèle de données sans l'installer dans une base de données. (- VS2010).

Dans l'ensemble, je dirais VS2010 sur un B-. C'était maladroit sur un projet de base de données relativement simple avec deux tables de faits et environ 15 dimensions.

Le plus grand modèle de données que j'ai jamais utilisé était celui d'un système de gestion des affaires judiciaires, qui comptait environ 560 tableaux. Je ne recommanderais pas VS2010 pour un projet de cette taille (je l'ai fait sur Oracle Designer). Essentiellement, il essaie d'être intelligent et le paradigme ne fonctionne pas vraiment bien. Vous êtes mieux avec un outil de modélisation de pointe comme PowerAMC ou simplement en utilisant la création de scripts de table à la main.

SSMS est simple et fiable mais manuel. Vous avez un contrôle à peu près infini sur la façon dont vous souhaitez gérer le modèle. Combinez-le avec un gestionnaire de schéma tel que Redgate SQL Compare et peut-être un outil de modélisation décent tel que PowerAMC et vous avez un package bien meilleur que VS2010.

Résumé Je ne suis pas sûr de pouvoir citer des fonctionnalités ou des avantages tueurs à part (peut-être) l'intégration avec des solutions VS contenant d'autres projets. Si vous avez déjà VS2010 premium ou ultime, vous obtenez un outil de développement de base de données quelque peu imparfait avec votre chaîne d'outils .Net. Il intégrera des projets DB dans votre solution VS, vous pouvez donc l'utiliser pour créer des scripts de déploiement sproc au moins.

Cependant, VS n'a pas d'outil de modélisation à proprement parler, donc PowerAMC ou même Erwin est meilleur à cet égard. La gestion des schémas de Redgate est bien meilleure et SQL Compare Pro est assez bon marché (environ 400 £ IIRC). IMHO SSMS fonctionne beaucoup mieux pour le développement T-SQL mais vous pouvez certainement le faire avec VS2010.

VS2010 premium n'est pas beaucoup moins cher qu'un outil de modélisation de base de données de pointe et VS2010 ultime est au moins aussi cher. Au détriment d'une intégration étroite avec votre projet VS, vous pourriez probablement faire mieux avec des outils tiers.

ne alternative

Je suppose qu'il ne faut pas trop scorcher VS2010 sans suggérer au moins une alternative et décrire ses avantages et ses inconvénients. Aux fins de cela, je vais assumer un grand projet. Bien que je fasse principalement du travail A/P ces jours-ci, j'ai été impliqué dans un projet de plus de 100 années-personnel où j'ai fait le modèle de données (et certains travaux de développement) et quelques autres dans la plage de 10 années-personnel, où j'ai principalement travaillé en tant qu'analyste ou développeur. La plupart du temps, je travaille sur des systèmes d'entrepôt de données, mais les grands projets étaient principalement des applications. Sur la base de mes expériences avec divers outils, voici quelques suggestions pour une chaîne d'outils alternative:

VS2010 professionnel ou supérieur. Vous voudrez peut-être ou non utiliser les fonctionnalités de gestion de projet de Premium ou Ultimate.
Subversion, AnkhSVN et TortoiseSVN - Mieux que TFS tous les jours et joue bien avec VS. Il est également tout à fait prêt à exploiter des dépôts locaux pour des flux de travail de développement simultanés.
SSMS pour le développement T-SQL - Gestion de projet et SC intégration pas si bonne mais fonctionne bien pour le travail de développement de base de données.
Projet VS2010 DB pour le suivi des fichiers sproc - légèrement maladroit si vous utilisez SSMS mais fonctionne bien. Il générera également des scripts de déploiement.
PowerAMC - Beaucoup mieux pour modéliser une base de données et gérer les éléments de schéma de base de données. Il fait également UML si vous souhaitez vous lancer dans MDA. Si vous souhaitez piloter votre conception de base de données à partir d'un modèle d'objet, vous pouvez plutôt envisager Sparx EA. Il fait le meilleur travail de Meta CASE (méta modèle extensible) de tout outil CASE que j'ai vu, bien que sa modélisation de base de données laisse à désirer.
SQL Compare pro - Utilisez-le pour générer des scripts de correctifs DB ou pour tester des scripts de correctifs manuels (voir 1 ci-dessous).
Framemaker - Fonctionnalités de groupware beaucoup plus stables et meilleures que Word si vous avez plusieurs analystes travaillant sur une spécification. Il prend également en charge l'inclusion conditionnelle, vous pouvez donc avoir des versions versionnées d'une spécification avec les modifications WIP masquées. MIF et MML facilitent l'intégration des documents API et des dictionnaires de données dans les documents de spécification. Il est très utile de le faire car vous pouvez ensuite les renvoyer dans la spécification. Les ancres textuelles des étiquettes rendent les références croisées stables lors des réimportations. Vous pouvez également utiliser TCS pour une source unique du document en sortie PDF, HTML et CHM.
Traqueur de problèmes open source - Beaucoup de bons logiciels open source (par exemple TRAC, Bugzilla pour nommer un couple que j'ai utilisé). Les logiciels libres sont plus faciles à modifier ou à intégrer dans un flux de travail personnalisé et vous ne pouvez pas battre le prix.
NUnit ou d'autres outils de test - quels que soient les outils de test automatisés les plus appropriés à vos besoins.
Tout sauf projet MS - considéré comme nuisible. Le projet MS est très tourné vers l'intérieur et force les plans de projet dans un modèle qui ne représente pas efficacement l'incertitude, le risque ou les dépendances des parties prenantes ou d'autres tiers (voir 2 ci-dessous).

Avantages: Meilleure modélisation de base de données et gestion de schéma que VS2010, meilleur système de contrôle de version, plus facile à personnaliser le flux de travail de construction et de projet, meilleure gestion des spécifications et de la documentation.

Inconvénients: Plus d'efforts pour intégrer les outils, intégration de base de données limitée dans le processus de construction.

Hypothèses: Suppose que le contrôle du processus de changement/version est plus important que la gestion des versions automatisée ou étroitement intégrée pour les schémas de base de données. Suppose également que la gestion automatisée du schéma de base de données n'est pas fiable à 100%.

Pas terriblement high-tech ou peu intégré, mais pour un projet complexe, vous êtes probablement plus intéressé par le contrôle que par de jolies fonctionnalités automatisées. Je dirais que vous êtes mieux avec un ensemble des meilleurs outils de race et quels que soient les scripts de construction et de test de brassage à domicile nécessaires pour les intégrer. Essayez simplement de garder la version (a) relativement simple à comprendre et (b) entièrement automatisée.

QA sur les correctifs DB. Sur un schéma de grande taille, vous souhaiterez peut-être avoir un processus de correction manuel pour les systèmes actifs, en particulier si les correctifs impliquent une migration des données. Par exemple, il peut être souhaitable de disposer de scripts de restauration et de restauration pour prendre en charge l'annulation d'une modification si nécessaire. Dans ce cas, vous voudrez avoir une installation pour tester que le patch fonctionne réellement correctement. Si vous gérez le schéma de base de données dans un référentiel, vous pouvez tester les scripts en configurant avant les bases de données et en générant une base de données de référence à partir du référentiel. L'exécution du script de correctif sur la base de données avant doit le synchroniser avec le modèle de référentiel. Un outil de comparaison de schéma peut être utilisé pour tester cela.
J'ai fait beaucoup plus d'entrepôt de données et de travail d'intégration que le développement d'applications sur mesure ces derniers temps, donc je le rencontre plus souvent qu'une équipe de développement ne le fera dans la plupart des cas. Cependant, les outils et méthodologies de gestion de projet font un très mauvais travail de gestion des parties prenantes externes. Dans un projet d'intégration tel qu'un entrepôt de données, je veux vraiment voir un outil de gestion de projet qui pousse vraiment les dépendances externes (c'est-à-dire celles que je ne contrôle pas) face à la gestion de programme. Sur tout projet d'intégration non trivial, les dépendances externes sont de loin les plus gros moteurs de perte de temps.

Mark Storey-Smith · Answer

J'ai essayé de structurer une réponse à cette question depuis qu'elle a été publiée à l'origine. C'est difficile car le cas de VS2010 ne consiste pas à décrire les fonctionnalités et les avantages de l'outil. Il s'agit de convaincre le lecteur de faire un changement fondamental dans son approche du développement de bases de données. Pas facile.

Il existe des réponses à cette question de professionnels chevronnés de la base de données, avec un mélange d'arrière-plan couvrant DBA, développeur/dba et les deux OLTP et entreposage de données. Il n'est pas viable pour moi d'aborder cela pour chaque facette de la base de données développement en une seule séance, donc je vais essayer de faire un cas pour un scénario particulier.

Si votre projet correspond à ces critères, je pense qu'il existe un argument convaincant pour VS2010:

Votre équipe utilise VS2010 pour le développement d'applications.
Votre équipe utilise TFS pour le contrôle des sources et la gestion des builds.
Votre base de données est SQL Server.
Votre équipe a déjà ou est intéressée par les tests automatisés VS.

Si vous évaluez VS2010 pour le développement de bases de données, votre bible sera Visual Studio Database Guide de Visual Studio ALM Rangers . Toutes les citations qui suivent sans références proviendront de ce document.

C'est parti alors ...

Pourquoi le processus de développement de base de données est-il différent du développement d'applications?

Les données. S'il n'y avait pas ces données embêtantes, le développement de la base de données serait un jeu d'enfant. Nous pourrions simplement supprimer tout sur chaque version et oublier cette gestion des changements gênante.

L'existence de données complique le processus de modification de la base de données car les données sont souvent migrées, transformées ou rechargées lorsque des modifications sont introduites par des efforts de développement d'applications qui affectent la forme des tables de la base de données ou d'autres schémas de données. Tout au long de ce processus de changement, les données de qualité de production et l'état opérationnel doivent être protégés contre les changements qui pourraient compromettre son intégrité, sa valeur et son utilité pour l'organisation.

Quel est le problème avec SSMS?

Cela s'appelle SQL Server Management Studio pour une raison. En tant qu'outil autonome, il n'est pas pratique de gérer vos efforts de développement si vous allez suivre les meilleures pratiques acceptées.

Avec les scripts seuls, pour appliquer de manière significative les pratiques de contrôle des sources établies à votre développement, vous devrez maintenir à la fois les définitions d'objets (par exemple, un script CREATE TABLE) ET changer les scripts (par exemple ALTER TABLE) ET travailler dur pour vous assurer qu'ils restent synchronisés.

La chaîne de versions pour les modifications apportées à une table devient assez stupide assez rapidement. Un exemple très simpliste:

-- Version 1 CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20)) -- Version 2 CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50)) -- Version 3 CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))

Par la version 3, le script de changement de base de données contient:

ALTER TABLE dbo.Widget ADD Description VARCHAR(50) ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)

Si la version live de cette base de données est la version 1 et notre prochaine version est la version 3, le script ci-dessous serait tout ce qui était nécessaire mais à la place les deux instructions ALTER seront exécutées.

ALTER TABLE dbo.Widget ADD Description VARCHAR(100)

5 ans de sprints de 4 semaines s'ajoutent à certains scripts de version divertissants et nécessitent une gestion supplémentaire de l'homme pour minimiser l'impact sur le temps de déploiement.

Y a-t-il un problème avec SSMS? Non, c'est bon pour ce que c'est bon, en administrant et en gérant SQL Server. Ce qu'il ne prétend même pas faire, c'est aider un développeur de base de données dans la tâche (parfois) très complexe de gestion du changement.

Si vous ne pouvez pas créer chaque version de la base de données à partir de la source et la mettre à niveau vers une version future, votre contrôle de source est rompu. Si vous ne le pensez pas, demandez à Eric Sink .

Qu'en est-il de SSMS + <- insérer l'outil de comparaison de schémas ->?

C'est certainement un pas dans la bonne direction et enlève une grande partie de l'effort manuel requis pour maintenir les scripts. Mais (et c'est un gros mais), il y a généralement des étapes manuelles impliquées.

Les outils de comparaison de schémas populaires peuvent être entièrement automatisés et intégrés au processus de construction. Cependant, d'après mon expérience, la pratique la plus courante consiste à exécuter une comparaison manuellement, les scripts résultants à l'œil nu, archivés au contrôle de code source, puis exécutés manuellement pour se déployer. Pas bon.

Chaque fois que nous, les humains faillibles, devons nous impliquer dans le processus de construction ou de déploiement, nous introduisons des risques et nous rendons le processus non reproductible.

Si vous et votre équipe êtes parmi les rares à avoir une comparaison et un déploiement de schémas entièrement automatisés, chapeau à vous! Vous êtes les plus susceptibles d'être ouverts aux avantages que VS2010 a à offrir en tant que:

Vous avez déjà accepté que les étapes manuelles sont dangereuses.
Vous voyez la valeur de l'automatisation.
Vous êtes prêt à investir le temps nécessaire pour le faire fonctionner.

Si vous ne pouvez pas créer une build en une seule étape ou déployer en une seule étape, votre processus de développement et de déploiement est interrompu. Si vous ne le pensez pas, demandez à Joel Spolsky .

Pourquoi VS2010?

La question posée par @NickChammas est à la recherche de fonctionnalités tueuses qui démontrent pourquoi VS2010 change la donne pour le développement de bases de données. Je ne pense pas que je puisse faire le cas sur cette base.

Peut-être de façon comique, là où d'autres voient des défauts dans cet outil, je vois de fortes raisons pour l'adoption:

Vous devrez changer votre approche.
Vous et votre équipe serez obligés de travailler différemment.
Vous devrez évaluer l'impact de chaque changement, longuement et en détail.
Vous serez guidé vers chaque changement idempotent .

Si vous êtes le seul DBA sur un projet, gérant toutes les modifications de la base de données, ce raisonnement doit sembler ridicule à la limite de l'absurde. Si toutefois vous pensez que @BrentOzar a raison et que l'une des nouvelles règles est que Tout le monde est le DBA , vous devrez contrôler les modifications de la base de données de manière à ce que tous les développeurs de l'équipe puissent travailler.

L'adoption de projets de base de données peut nécessiter un changement mental ( les vieilles habitudes sont difficiles à briser ) pour certains développeurs ou au moins un changement de processus ou de workflows. Les développeurs qui ont développé des applications de base de données où la base de données de production représente la version actuelle de la base de données devront adopter une approche basée sur le code source où le code source devient le véhicule vers lequel les modifications sont apportées aux bases de données . Dans les projets de base de données Visual Studio, le projet et le code source sont la "version unique de la vérité" pour le schéma de base de données et sont gérés à l'aide de workflows SCM probablement déjà utilisés par le développeur ou l'organisation pour d'autres parties de leur pile d'applications. Pour les données, la base de données de production reste sa "One Version of the Truth" comme il se doit.

Nous sommes arrivés au virage fondamental nécessaire pour adopter avec succès l'approche VS2010 en matière de développement de bases de données…

Traitez votre base de données comme du code

Plus besoin de changer la base de données en direct. Chaque changement de base de données suivra le même modèle qu'un changement d'application. Modifiez la source, créez, déployez. Ce n'est pas un changement de direction temporaire de Microsoft, c'est l'avenir de SQL Server . Base de données sous forme de code est là pour rester.

Le développeur de la base de données définit la forme de l'objet pour la version de l'application, et non la façon de faire muter l'objet existant dans le moteur de base de données à la forme souhaitée. Vous vous demandez peut-être: comment cela est-il déployé sur une base de données qui contient déjà la table client? C'est là que le moteur de déploiement entre en jeu. Comme mentionné précédemment, le moteur de déploiement prendra la version compilée de votre schéma et la comparera à une cible de déploiement de base de données. Le moteur de différenciation produira les scripts nécessaires pour mettre à jour le schéma cible pour correspondre à la version que vous déployez à partir du projet.

Oui, il existe d'autres outils qui suivent un modèle similaire et pour les projets en dehors des contraintes que j'ai imposées à ma réponse, ils valent la même considération. Mais, si vous travaillez avec Visual Studio et Team Foundation Server ALM, je ne pense pas qu'ils puissent rivaliser.

Quel est le problème avec les projets de base de données VS2010?

Ils ne sont pas parfaits . Mais si vous êtes conscient des limites et des problèmes, vous pouvez les contourner.
Mouvements de données complexes nécessitent toujours du soin et de l'attention mais sont pris en charge avec des scripts de déploiement avant/après.

Edit: Alors quel est votre point alors?

@AndrewBickerton a mentionné dans un commentaire que je n'ai pas répondu à la question d'origine, je vais donc essayer de résumer "Pourquoi devrais-je utiliser Visual Studio 2010 sur SSMS pour le développement de ma base de données?" ici.

SSMS n'est pas un outil de développement de base de données. Oui, vous pouvez développer TSQL avec SSMS mais il ne fournit pas les riches fonctionnalités IDE de VS2010.
VS2010 fournit un cadre pour traiter votre base de données comme du code.
VS2010 apporte analyse de code statique à votre code de base de données.
VS2010 vous fournit les outils pour automatiser entièrement le cycle de construction-déploiement-test.
SQL2012 et Visual Studio vNext étendent les capacités des projets de base de données. Familiarisez-vous avec VS2010 maintenant et vous avez une longueur d'avance sur les outils de développement de bases de données de nouvelle génération.

gbn · Answer

VS peut sembler génial si vous ne connaissez pas SSMS ou si vous avez utilisé des outils tiers. Les lacunes de VS ressortent si vous utilisez les outils Red Gate pour la comparaison de schémas, etc. Et les plug-ins SSMS gratuits aussi.

Les bits de contrôle de source sont trompeurs: ce qui se trouve dans la base de données de production est votre copie de référence. Pas ce que le développeur utilise. Voir

Peter Schofield · Answer

J'utilise beaucoup Visual Studio (enfin, BIDS) pour la conception de rapports SSRS et les packages SSIS. Je ne pouvais pas faire très bien non plus, voire pas du tout, dans Management Studio. Visual Studio est un environnement de développement beaucoup plus complet et intégré, et il s'intègre beaucoup mieux aux systèmes de contrôle de source. Et tout cela se reflète dans le prix!

Thomas Stringer · Answer

Pour être honnête, mon vote va directement à SQL Server Management Studio pour la conception, le développement et (évidemment) l'administration de la base de données. Il est simplement plus facile de taper:

create table newTable ( someId int identity(1, 1) not null primary key clustered, ...... you get the idea )

Cliquez ensuite aux bons endroits. SSMS est une excellente mise en page et un plaisir absolu à travailler. Et je suis un développeur de logiciels .NET par nature. Mais en ce qui concerne la conception et le codage des bases de données, je choisirai SSMS 11 fois sur 10.

Nico · Answer

Il n'y a pas de meilleure pratique, mais avec le projet de base de données VS 2010 et le contrôleur de code source (VSS 2010, Subversion, etc.), vous pouvez versionner votre base de données.

Je vous recommande de concevoir d'abord votre base de données directement dans SSMS. Une fois votre base de données presque prête, importez-la dans un projet de base de données VS 2010. Une fois l'importation terminée, vous devez toujours ajouter un nouveau script dans votre projet de base de données pour suivre toutes les modifications. Vous pouvez utiliser la fonction de comparaison du projet de base de données pour obtenir toutes les modifications du serveur de développement et importer tous ces scripts directement dans votre projet. Il ne vous reste plus qu'à "valider" votre modification dans votre contrôleur de code source.

Avec cette méthode, vous pouvez avoir une base de données versionnée. Vous pouvez repérer la version de chaque modification et annuler vos modifications.

Ce n'est pas le seul avantage. Avec ce type de projet, vous pouvez comparer n'importe quelle base de données à votre projet pour écrire les modifications et avec l'invite de commande SQL PowerShell, vous pouvez mettre à jour toutes vos bases de données avec le même script: ce script est un schéma XML de votre base de données. Il exécutera uniquement les commandes nécessaires pour mettre à jour vos bases de données. Vous avez également la possibilité de faire test unitaire dans votre base de données. Un autre bon article pour le projet de base de données est disponible ici . Avec la fonction de déploiement, vous pouvez avoir un pré-script et un post-script. Avec ces scripts, vous pouvez avoir une validation ou insérer des données dans vos tables système.

Ici est une bonne procédure étape par étape pour le projet de base de données.

user507 · Answer

J'utilise SSMS plus que VS2010 car il est là lorsque j'installe SQL Server. C'est probablement la chose la plus importante pour laquelle SSMS est utilisé plus que VS2010, à mon humble avis.

J'ai également constaté que des fournisseurs comme Red-Gate proposent des outils qui s'intègrent avec SSMS et pas nécessairement VS2010. Cela peut être positif dans la mesure où il vous permet d'améliorer SSMS là où Microsoft ne l'a pas fait. Un exemple de cela est le contrôle de source SQL de Red-Gate, qui est un module complémentaire de SSMS qui vous permet de connecter SSMS au système de contrôle de source de votre entreprise, que ce soit Visual Team Foundation ou ce que vous avez. VS2010 a cette fonction intégrée, mais par rapport au prix de l'outil Reg-Gate, je viens d'économiser beaucoup d'argent sans avoir à acheter VS2010.

Je pense que dans l'ensemble, cela dépend de la préférence, vous travaillez avec ce que vous êtes à l'aise. Si vous formez une nouvelle personne et que vous la formez sur VS2010, cela deviendra sa préférence car elle sait comment s'y prendre.

Si vous avez commencé à jouer avec SQL Server 2012, vous avez peut-être remarqué que SSMS obtient la composition de VS2010 lentement mais sûrement. Donc, finalement, vous ne pourrez peut-être pas faire la différence entre eux.