Création d'un projet de base de données sans SQL local installé

Question

Je ne suis peut-être pas d'accord avec cela, mais existe-t-il un moyen de faire pointer un projet de base de données vers un serveur distant? Ma raison de demander est que nous avons une base de données DEV partagée pour l'utilisation de développement, et il semble que chaque développeur ait trop d'avoir une instance locale de SQL Server. Y a-t-il une chaîne de connexion que je peux définir ou modifier pour pointer le serveur distant, ou est-ce que la seule façon d'avoir un projet de base de données est d'avoir une instance locale sur votre machine. S'il vous plaît laissez-moi savoir si ce que je demande n'a pas de sens.

Merci!

Answer 1

SQL Server Data Tools (qui est ce que vous utilisez pour votre projet de base de données) peuvent travailler de deux façons:

1. Connected Database mode.
2. Project oriented, offline database mode.

Si vous regardez ces articles. vous verrez qu'à des fins de développement, dans les deux cas, une instance localdb est nécessaire. Le serveur local est une installation SQL Server Express limitée, qui est fournie par défaut avec Data Tools. Tout ce que vous avez à faire est d'installer des outils de données. Si vous l'avez déjà fait, vous disposez du support localdb. Plus sur ce MSDN:

Microsoft SQL Server 2012 fournit un local sur la demande instance de serveur, appelé SQL Server Express Base de données locale Runtime, qui est activé lors du débogage d'un projet de base de données SQL Server. Cette instance de serveur local peut être utilisée comme sandbox pour la construction, le test et le débogage de votre projet. Il est indépendant de l'une de vos instances SQL Server installées et n'est pas accessible en dehors des outils de données SQL Server (SSDT).

Le flux de travail, pour une base de données centrale de développement, serait:

• Créer le projet de base de données et le distribuer à chaque développeur.
• Les développeurs travaillent hors ligne et ajoutent/suppriment des objets de la base de données.
• Avant de soumettre les modifications au contrôle de source, chaque développeur synchronise également les modifications de la base de données locale avec la base de données de développement centrale.
• Le reste de l'équipe reçoit les modifications du contrôle de la source, donc aucune synchronisation manuelle n'est nécessaire. Seule une nouvelle publication localedb serait requise.

Bien sûr, il y a beaucoup d'autres choses à prendre en considération: les données locales (voir here sur la réplication des données à la base de données réelles), et certaines fonctionnalités ne sont pas pris en charge par localdb (comme la recherche en texte intégral).

J'ai essayé ce flux et fonctionne très bien si vous apprenez à le contrôler. Vous obtenez toujours une base de données de développement centrale cohérente, sans modifications intermédiaires et instables.

Answer 2

Vous pouvez modifier les propriétés "Débogage" pour pointer vers un serveur différent de l'instance (localdb). La plupart du temps vous ne le ferez pas à moins que vous n'utilisiez des fonctionnalités qui ne sont pas supportées par (localdb). Cela vous permettrait de pousser les changements sur votre serveur central sur chaque build de débogage. Cependant, cela pourrait avoir beaucoup de conséquences inattendues si vous ne faites que jouer.La meilleure option consisterait à laisser l'instance de débogage (localdb) seule et à configurer les profils de publication pour une véritable installation SQL Server «locale» et pour votre serveur de développement partagé. De cette façon, vous pouvez effectuer tous vos travaux de développement en mode hors connexion et n'apporter des modifications au serveur de développement partagé que lorsque vous êtes prêt à le faire.

J'ai une série d'articles de blog sur SSDT sur mon blog qui peut être utile: http://schottsql.blogspot.com. Je vous recommande également de regarder le blog de Jamie Thomson au http://sqlblog.com - il a beaucoup de conseils sur les projets DB et SQL qui pourraient être utiles.