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

Visual Studio 2010 introduit les projets de base de données et toute une gamme de fonctionnalités connexes censées faciliter le développement de la base de données. J'ai utilisé SQL Server Management Studio (SSMS) pendant de nombreuses années pour développer ma base de données sans problème.

• Pourquoi devrais-je me soucier de VS2010 quand SSMS fonctionne pour moi? Qu'est-ce que cela fait mieux que SSMS?
• Mais peut-être que mon hypothèse est incorrecte et que SSMS l'emporte toujours sur VS pour le développement de bases de données. Si oui, de quelle manière spécifique est-ce vrai?

En fait, j’étais un peu dépassé par VS2010, pour être honnête. Je pense qu’il est plus facile de travailler avec un script de table de création de vieille école et des fichiers de 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 travail bien meilleur, même s'il n'est 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. Construire et utiliser des scripts de création est beaucoup plus pratique que les cerceaux que VS2010 vous oblige à franchir. Beaucoup, beaucoup plus flexible (+ SSMS).

• VS2010 a une gestion de base des schémas (c'est-à-dire une génération de script de différence / correctif) (+ VS2010). Cependant, ce n'est pas si bon et il y a des 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 autre machine car les contraintes peuvent avoir des noms différents. Redgate est moins cher et mieux. (+ VS2010, mais imparfait).

• VS2010 est vraiment maladroit - vous devez disposer d'un fichier pour chaque table ou autre objet de base de données. Vous devez essentiellement faire les choses de la manière VS2010, ce qui est assez lourd. (- VS2010)

• VS2010 est également quelque peu fragile et l’intégration du contrôle de la source est complexe. 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 constitue 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 des fichiers du projet lorsque les enregistrements sont désynchronisés. Même avec une bonne discipline d'équipe, le retour d'information de la part de l'interface utilisateur est très faible. Ce serait un désastre sur un modèle complexe. (-VS2010 - Je considérerais presque cela comme un défaut flagrant pour un grand projet).

• SSMS est livré avec SQL Server - le prix est imbattable (+ SSMS).

• VS2010 ne dispose toujours pas d'un référentiel approprié, tel que (disons) 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 donnerais à VS2010 la note d'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é concerne un système de gestion des procédures judiciaires, qui compte environ 560 tables. Je ne recommanderais pas VS2010 pour un projet de cette taille (je l'avais fait sous Oracle Designer). Essentiellement, il s'agit d'essayer d'être intelligent et le paradigme ne fonctionne pas très bien. Mieux vaut utiliser un outil de modélisation de premier ordre tel que PowerAMC ​​ou simplement utiliser les scripts de création de table à la main.

SSMS est simple et fiable mais manuel. Vous avez un contrôle quasi 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 approprié tel que PowerAMC ​​et vous aurez un package bien meilleur que VS2010.

Résumé Je ne suis pas sûr de pouvoir citer des fonctionnalités ou des avantages exceptionnels, à part (peut-être) l’intégration avec des solutions VS contenant d’autres projets. Si vous possédez déjà VS2010 premium ou ultime, votre outil de développement de base de données est quelque peu défectueux avec votre chaîne d'outils .Net. Il intégrera les projets de base de données dans votre solution VS afin que vous puissiez l'utiliser au moins pour créer des scripts de déploiement sproc.

Cependant, VS n'a pas d'outil de modélisation, 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 relativement 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 premier ordre, tandis que VS2010 ultimate est au moins aussi cher. Au prix d'une intégration étroite avec votre projet VS, vous pourriez probablement faire mieux avec des outils tiers.

Une alternative

Je suppose qu’il ne faut pas trop écraser VS2010 sans suggérer au moins une alternative et en exposer les avantages et les inconvénients. Aux fins de ceci, je suppose un grand projet. Bien que je travaille principalement en comptabilité ces derniers jours, j'ai participé à un projet de plus de 100 années au sein duquel j'ai utilisé le modèle de données (et quelques travaux de développement), ainsi que quelques autres dans la tranche des 10 années au sein de laquelle 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 plus gros projets étaient principalement des applications. Sur la base de mes expériences avec différents outils, voici quelques suggestions pour une chaîne d’outils alternatifs:

• VS2010 professionnel ou supérieur. Vous pouvez ou non utiliser les fonctionnalités de gestion de projet Premium ou Ultimate.
• Subversion, AnkhSVN et TortoiseSVN - Mieux que TFS tous les jours et s’agrandit bien avec VS. Il est également tout à fait apte à exploiter des référentiels locaux pour des flux de travail de développement simultanés.
• SSMS pour le développement T-SQL - La gestion de projet et l’intégration SC ne sont pas très bonnes mais fonctionnent bien pour le développement de bases de données.
• Projet de base de données VS2010 pour le suivi des fichiers sproc - légèrement maladroit si vous utilisez SSMS mais fonctionne correctement. Il générera également des scripts de déploiement.
• PowerAMC ​​- Mieux faire pour modéliser une base de données et gérer des éléments de schéma de base de données. Il utilise également UML si vous souhaitez vous impliquer fortement dans MDA. Si vous souhaitez gérer votre conception de base de données à partir d'un modèle objet, vous pouvez plutôt envisager Sparx EA. Il fait le meilleur travail de Meta CASE (méta modèle extensible) de tous les outils CASE que j'ai vus, 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 de base de données ou pour tester des scripts de correctifs manuels (voir 1 ci-dessous).
• Framemaker - Des fonctionnalités de collecticiel beaucoup plus stables et meilleures que Word si plusieurs analystes travaillent sur une spécification. Il prend également en charge l'inclusion conditionnelle. Vous pouvez donc masquer les versions versionnées d'une spécification avec les modifications WIP. MIF et MML facilitent l'intégration des documents API et des dictionnaires de données dans les documents de spécifications. Il est très utile de le faire car vous pouvez ensuite les référencer dans la spécification. Les ancres d'étiquettes textuelles rendent les références croisées stables lors des réimportations. Vous pouvez également utiliser TCS pour externaliser le document en format 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 à code source ouvert sont plus faciles à modifier ou à intégrer dans un flux de travail personnalisé et le prix est imbattable.
• NUnit ou d'autres outils de test - quels que soient les outils de test automatisés les mieux adaptés à vos besoins.
• Tout sauf le projet MS - Considéré comme nuisible. MS Project est très replié sur lui-même et force les plans de projet dans un modèle qui ne représente pas efficacement les incertitudes, les risques ou les dépendances vis-à-vis des parties prenantes ou d’autres tiers (voir 2 ci-dessous).

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

Inconvénients: Intensifier les efforts d'intégration des outils, intégration limitée de la base de données dans le processus de construction.

Hypothèses: Suppose que le contrôle du processus de modification / édition 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 des schémas de base de données n’est pas fiable à 100%.

Pas très sophistiqué, ni parfaitement 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 feriez mieux de disposer d'un ensemble d'outils de pointe et que tout ce qui est nécessaire pour créer et tester des scripts maison est nécessaire pour les intégrer. Essayez simplement de garder la construction (a) relativement simple à comprendre et (b) entièrement automatisée.

1. QA sur les correctifs de base de données. Sur un schéma volumineux, vous souhaiterez peut-être un processus de correction manuel pour les systèmes actifs, en particulier si les correctifs impliquent une migration de données. Par exemple, il peut être souhaitable de disposer de scripts de reprise et de reprise pour prendre en charge la sauvegarde d'une modification, si nécessaire. Dans ce cas, vous souhaiterez disposer d’une fonction permettant de vérifier que le correctif fonctionne 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 référence à partir du référentiel. L'exécution du script de correctif sur la base de données before devrait le synchroniser avec le modèle de dépôt. Un outil de comparaison de schéma peut être utilisé pour tester cela.

2. J'ai effectué beaucoup plus de travail d'entreposage de données et d'intégration que de développement d'applications sur mesure ces derniers temps. C'est donc ce que je rencontre plus souvent qu'une équipe de développement. Cependant, les outils et les méthodologies de gestion de projet font très mal la gestion des parties prenantes externes. Dans un projet d'intégration tel qu'un entrepôt de données, je souhaite vraiment voir un outil de gestion de projet qui insiste vraiment sur les dépendances externes (c'est-à-dire celles que je ne contrôle pas) face à la gestion de programme. Dans tous les projets d’intégration non triviaux, les dépendances externes sont de loin les principaux facteurs de perte de temps.

Je me suis demandé comment structurer une réponse à cette question depuis sa publication initiale. Ceci est difficile car le cas de VS2010 ne consiste pas à décrire les caractéristiques et les avantages de l'outil. Il s’agit de convaincre le lecteur de modifier radicalement son approche du développement de bases de données. Pas facile.

Il existe des réponses à cette question de professionnels expérimentés dans les bases de données, avec un mélange de fond englobant DBA, développeur / dba et OLTP et entreposage de données. Il n'est pas viable pour moi d'aborder cette question pour chaque aspect du développement de la base de données en une seule fois. Je vais donc essayer de défendre un scénario en particulier.

Si votre projet répond à 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 de source 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 le Guide de base de données Visual Studio des Visual Studio ALM Rangers . Toutes les citations qui suivent et qui n’ont pas de références seront extraites 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. Sans ces données embêtantes, le développement de la base de données serait un jeu d'enfant. Nous pourrions tout laisser tomber à chaque version et oublier cette gestion de changement gênante.

L'existence de données complique le processus de modification de la base de données car celles-ci sont souvent migrées, transformées ou rechargées lorsque des modifications sont introduites par les 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 susceptibles de 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 souhaitez suivre les meilleures pratiques acceptées.

Avec les scripts uniquement, pour appliquer de manière significative les pratiques de contrôle de code source établies à votre développement, vous devez gérer les deux définitions d’objet (par exemple, un script CREATE TABLE) ET modifier les scripts (par exemple, ALTER TABLE) ET travailler sans relâche pour s’assurer qu’elles restent synchronisées.

La chaîne de versions pour les modifications apportées à une table devient assez rapide. 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 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 en direct de cette base de données est la version 1 et que notre prochaine version est la version 3, le script ci-dessous serait tout ce qui était nécessaire, mais les deux instructions ALTER seront exécutées.

ALTER TABLE dbo.Widget ADD Description VARCHAR(100)

Les sprints de 5 ans sur 4 semaines s'ajoutent à certains scripts de version divertissants et nécessitent une manipulation plus manuelle afin de minimiser l'impact sur le temps de déploiement.

Alors, y a-t-il un problème avec SSMS? Non, c’est bon pour l’administration et la gestion de SQL Server. Ce qu'il ne prétend même pas faire, c'est d'assister un développeur de bases 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 ultérieure, votre contrôle de code source est rompu. Si vous ne le pensez pas, demandez à Eric Sink .

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

Il s’agit bien d’un pas dans la bonne direction qui supprime l’essentiel des efforts manuels nécessaires à la maintenance des scripts. Mais (et c'est un gros mais), il y a généralement des étapes manuelles.

Les outils de comparaison de schéma courants peuvent être entièrement automatisés et intégrés au processus de construction. Cependant, selon mon expérience, la pratique la plus courante consiste à exécuter une comparaison manuellement, à analyser les scripts résultants, à les archiver dans le contrôle de code source, puis à les exécuter manuellement pour les déployer. Pas bon.

Chaque fois que nous sommes faillibles, les êtres humains doivent participer au processus de construction ou de déploiement, nous introduisons des risques et nous rendons le processus non répétable.

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

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

Si vous ne pouvez pas créer une construction 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 de rechercher des fonctionnalités exceptionnelles démontrant pourquoi VS2010 change la donne pour le développement de bases de données. Je ne pense pas pouvoir argumenter sur cette base.

Peut-être comiquement, là où d'autres voient des failles dans cet outil, je vois de bonnes raisons pour l'adoption:

• Vous devrez changer votre approche.
• Vous et votre équipe serez obligés de travailler d'une manière différente.
• Vous devrez évaluer l'impact de chaque changement, en détail et en détail.
• Vous serez guidé pour rendre chaque changement idempotent .

Si vous êtes le seul administrateur de base de données sur un projet, gérant toutes les modifications apportées à la base de données, ce raisonnement doit sembler ridicule à la limite de l'absurde. Si toutefois vous pensez que @BrentOzar a un sens et que l'une des nouvelles règles est que Tout le monde est administrateur de base de données, 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.

Adoption de la base de données Les projets peuvent nécessiter un changement de mentalité (les vieilles habitudes sont difficiles à rompre ) pour certains développeurs ou au moins un changement de processus ou de flux de travail. Les développeurs qui ont développé des applications de base de données dans lesquelles 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, le code source devenant le moyen de modification des bases de données . Dans les projets de base de données Visual Studio, le projet et le code source constituent la "version unique de la vérité" pour le schéma de base de données et sont gérés à l'aide de flux de travaux SCM susceptibles d'être déjà utilisés par le développeur ou l'organisation pour d'autres parties de la pile de leurs applications. Pour les données, la base de données de production reste sa "version unique de la vérité" comme il se doit.

Nous sommes arrivés au changement fondamental nécessaire pour adopter avec succès l'approche de développement de base de données VS2010…

Traitez votre base de données comme un code

Pas plus de changer la base de données en direct. Chaque changement de base de données suivra le même schéma qu'un changement d'application. Modifier la source, construire, déployer. Ce n'est pas un changement de direction temporaire de Microsoft, c'est l'avenir de SQL Server . La base de données en tant que code est là pour rester.

Le développeur de base de données définit la forme de l'objet pour la version de l'application, et non la manière de transformer l'objet existant dans le moteur de base de données en forme souhaitée. Vous vous demandez peut-être: comment cela est-il déployé sur une base de données contenant déjà la table client? C'est là que le moteur de déploiement entre en jeu. Comme indiqué précédemment, le moteur de déploiement utilise la version compilée de votre schéma et la compare à 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 afin qu'il corresponde à la version que vous déployez à partir du projet.

Oui, il existe d’autres outils qui suivent un modèle similaire et pour des projets qui ne sont pas soumis aux contraintes que j’ai posées sur ma réponse, ils méritent une attention égale. Toutefois, si vous travaillez avec ALM Visual Studio et Team Foundation Server, 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 limitations et des problèmes, vous pouvez les contourner.
• Les mouvements de données complexes nécessitent toujours du soin et de l'attention, mais sont pris en charge avec des scripts de pré / post déploiement.

Edit: Alors, quel est votre point alors?

@ AndrewBickerton a mentionné dans un commentaire que je n'avais pas répondu à la question initiale. Je vais donc 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 cela ne fournit pas les fonctionnalités IDE riches de VS2010.
• VS2010 fournit un cadre pour traiter votre base de données en tant que code.
• VS2010 apporte l'analyse de code statique à votre code de base de données.
• VS2010 vous fournit les outils pour automatiser complètement le cycle de test construction / déploiement.
• SQL2012 et Visual Studio vNext étendent les capacités des projets de base de données. Familiarisez-vous avec VS2010 maintenant et vous aurez une longueur d'avance sur les outils de développement de bases de données de nouvelle génération.

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

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

• https://stackoverflow.com/q/1597085/27535
• https://stackoverflow.com/q/4433153/27535

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

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

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

Puis cliquez dans tous les bons endroits. SSMS est une excellente mise en page et une explosion de travail. Et je suis, par nature, un développeur de logiciels .NET. Mais pour ce qui est de la conception et du codage des bases de données, je choisirai SSMS 11 fois sur 10.

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 mettre à jour 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 fonctionnalité 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 avec votre projet pour écrire les modifications. 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 n'exécutera que les commandes nécessaires pour mettre à jour vos bases de données. Vous avez également la possibilité de faire des tests unitaires dans votre base de données. Un autre bon article pour le projet de base de données est disponible ici . Avec la fonctionnalité de déploiement, vous pouvez avoir un pré-script et un post-script. Avec ces scripts, vous ne pouvez ni valider ni insérer de données dans vos tables système.

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

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

J'ai également constaté que des fournisseurs tels que Red-Gate développent des outils qui s'intègrent à SSMS et pas nécessairement à VS2010. Cela peut être positif car cela vous permet d'améliorer SSMS là où Microsoft ne l'a pas encore fait. Le contrôle de source SQL de Red-Gate en est un exemple. Il s'agit d'un add-on à 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 autre. VS2010 a cette fonction intégrée, mais comparée au prix de l'outil de Reg-Gate, je viens d'économiser beaucoup d'argent sans avoir à acheter VS2010.

Je pense que dans l’ensemble, il s’agit de 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 leur préférence car elle sait comment se débrouiller.

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