Starting Team Development of Databases
Before you can manage changes to a database schema, you first create a database project, and then you import objects and settings from the database that you want to manage.
A database project contains the object definitions and deployment scripts that you would need to create a separate instance of that database or to update an existing instance. Because a database project is an offline representation of the database, you can put it under version control and then deploy iterative changes to an isolated development environment. Team members can test their changes independently and then share those changes with the team after they are fully tested. By taking this approach, you help control the quality of the database code before you deploy it to a production environment.
Specifying a Type of Database Project
When you create a database project, you specify the type of project that corresponds to your version of SQL Server. For example, if the database that you want to manage is based on SQL Server 2005, you specify either SQL Server 2005 Database Project or SQL Server 2005 Wizard. If you use the wizard, you can not only create the project, but also configure some build and deployment settings and import database objects and settings at the same time.
Importing Database Objects and Settings
After you create the project, you can import the objects and settings from a database instance or from a script. When you import a database, its object definitions are validated, and statements that cannot be parsed are put in the ScriptsIgnoredOnImport.sql file. If you import object definitions that reference objects that no longer exist, you must resolve those errors before you can build and deploy the project. For example, you might import a stored procedure that references a table that no longer exists. To resolve the error, you could remove that stored procedure.
You might have to spend a lot of time resolving such errors when you import a large schema. However, team members cannot unknowingly introduce additional errors of this kind as they update the schema in Visual Studio Premium. When they modify and save any object definition, all changes are validated so that team members can fix them immediately and avoid deploying those errors to a live database. After you resolve warnings in object definitions, you should also consider analyzing your database code for design issues, naming issues, and performance issues. For more information, see Analyzing Database Code to Improve Code Quality.
Depending on the development methodology of your team, you might perform the tasks in the following table when you start team development of your database project:
Learn more about database projects: You can read about the basic concepts of how to manage schema changes by using database projects.
Get hands-on practice: You can follow an introductory walkthrough to become familiar with how to create an isolated development environment, so that your changes will not conflict with changes from other team members. You can also follow more-specific walkthroughs that cover smaller sections of the database development life cycle.
Put an existing database schema under version control: You can create a project, configure project settings, and import a schema by using the database project wizard. You can also create an empty project if you want to import the schema later or if you do not have permission to access the database from which you want to import the schema. After you import the schema, you can add the project to version control.
Starting Team Development of Databases that Reference Other Databases
Describes how you can create an offline representation of a database schema, define one or more references to other databases, define variables for target deployment environments, and add the project to version control.
Starting Team Development of Databases that Reference SQLCLR Objects
Describes how you can create an offline representation of a database schema, define references to assemblies that contain SQL common language run-time (CLR) objects, define database objects that reference those objects, and add the project to version control.
Starting Team Development of Large Databases
Describes how you can create an offline representation of a database schema, spread across multiple projects, to restrict access to parts of the database schema. You can also use this approach to improve performance if you work with large databases.
Starting Team Development of Databases that Reference Shared Server Objects
Describes how you can create an offline representation of a database schema, define references to a shared server project, add references to objects that are defined in the server project, and add the database project to version control.
Starting Team Development of Databases that Use XML Schema Collections
Describes how you can create an offline representation of a database schema, reference an XSD schema, and use that referenced schema for typed XML columns in your tables.
Merging Multiple Databases into a Database Project
Describes how you can take objects that are defined in multiple databases and merge them into one database project.