An Overview of Database and Server Projects
You can help your organization manage its database development more effectively by creating a database project or a server project and putting it under version control. These offline representations contain the object definitions, settings, and deployment scripts that you could use to create a separate instance of that database (or server) or to update an existing instance.
Based on your organization's needs, you can also share parts of projects or create a composite project. For more information, see Sharing Parts of Projects later in this topic, or the "Composing Projects by Using References" section of Using References in Database Projects.
Solution Explorer shows your project organized by file. Each item in Solution Explorer corresponds to a saved file or a folder. In contrast, Schema View shows your project organized by object or by schema, so that you can identify objects in your database whether they are defined in separate files or not.
A database or server project can contain the following types of objects:
After you create a 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 need to spend a lot of time resolving such errors after you import a large schema. However, team members cannot unknowingly introduce additional errors of this type as they update the schema in Database Edition. 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 issues around design, naming, and performance. For more information, see Improving Database Code with Static Analysis.
If you want to re-use a set of files in more than one project, you can export any part of a project as a partial project. This action creates a .files file, which you can include in one or more other projects. For example, you might have some common stored procedures that you use to audit all your databases. You can define these stored procedures in one project, export them, and include them in your other projects. By taking this approach, you avoid having to maintain the same code in more than one project. For more information, see How to: Import and Export Partial Database Projects.
Your database projects and any related .dbschema files contain information about your database assets. In much the same way that you would restrict access to the source code, you should restrict access to your database projects and .dbschema files.
You can use the following methods to control access to your database projects and .dbschema files: