I work in a team of developers and we currently manage our SQL Server database schema (tables, stored procedures, user defined types, etc) through TFS and Visual Studio using a database project. We keep our local development copies of the database in sync using the Schema Compare tools in Visual Studio.
I'm currently setting up partitioning on a couple of huge tables of data which has resulted in 500+ FileGroups & Files based partly on what data we want to be on SSDs vs. spinning HDDs.
My question is, does anyone have a suggestion or experience on how to manage the database schema in TFS such that each developer doesn't have to setup the 500+ FileGroups/Files on each development machine?
The reason I want to avoid this is because
On our development machines we will only have a small amount of data
loaded based on disk space.
We plan to have a maintenance job on our production server to move data from SSD partitions to HDD partitions based on age. This means our production partitioning function won't match our development machines for very long anyway.
First, for your situation you can try to use server workspace. When you need to modify the files or projects, you just need to check out them.
When you use a server workspace, Visual Studio keeps only one copy of
each file. This can significantly reduce disk space usage and
improve performance when you have a lot of items. We recommend that
you use a server workspace if:
Your workspace contains more than 100,000 items.
You want to use Visual Studio 2010 or earlier versions to work with the workspace.
You need to use the Enable get latest on check-out option.
I'm not sure how did you handle the a database project. About how to put an existing database under source control, which consists of the following steps:
You create a database project.
You connect to an existing database.
You import the database schema from the existing database into the
database project.
You review the results that are shown in the database project.
You put the database project and its contents under version control.
You can also use a SSDT Database Project For Your Data Warehouse. Below is an example of how you could structure your database project (am only showing a few tables and views in the screen shots for brevity). You don't have to structure it this way, but in this project it's sorted first by schema, then by object type (table, view, etc), then by object (table name and its DDL, etc).
More detail info please refer this blog:Why You Should Use a SSDT Database Project For Your Data Warehouse
Related
For example, table T has 3 columns, id, name, city. Now, I add a new column country in the testing environment. I want to sync this change (database structure or scheme) instead of executing this script again in the staging and production environments.
I would probably suggest that this isn’t the pattern I would go with. Linking your environments together like that is bound to cause issues.
In the past I have use SQL Server database projects in Visual Studio. These projects allow you to define the structure of your database in SQL syntax and a nice GUI.
Microsoft article showing how to create one
This means you can put the project into a git repo and then create a deployment pipeline to promote the changes through the environment stages.
The compiled output of the project is called a dacpac and the tooling compares your target db with the structure in the dacpac and makes it match. You can control how it does that through config e.g. don’t drop tables, etc.
Microsoft article showing deployment steps
Overall this will give you a more refined control over the database schema.
What are advantages of using SQL Server Database Project in VS 2013?
Currently I dont use this on my project, I am generate script from SQL Server Management.
Should I move to Database Project? How complicated is?
There are many advantage of sql project.
1.Easily deployable in any conditions.
2.You can view history of db objects
3.You can maitain all db objects under on roof.
Effectively, a database project converts all of the objects in your database (table designs, stored procedures) into text files -- text files that can be searched, modified and stored in source control just like your code files. A database project also includes designers for working with these files. Visual Studio cross-references those files to give you a higher level of IntelliSense support for working with stored procedures than you'll ever get in SQL Server Management Studio.
You also get a staging database where you can make your changes before updating your production or development database and a schema comparison tool for determining, after the fact, what changes you've made. Effectively, you get an isolated database environment for trying out database changes.
I am needing to move all of my stored procedures into TFS 2012. I was wondering what the best/fastest way to accomplish this is. I am using SQL Server 2012.
Our suggestion would be to use the SQL Server Data Tools (SSDT) and create a database schema change management project in Visual Studio that you can then check-in to Team Foundation Server. It has quite a few benefits like being able to "compile" the schema and has tools that can be used in generating automatic change scripts for target servers (whether they are empty, test, or even production servers).
http://msdn.microsoft.com/en-us/data/tools.aspx
SSDT is definitely the way to go, It's a component of Visual Studio. There is an SSDT for database projects, and SSDT-BI for reports etc.
Create a database project in Visual Studio and add your database objects (stored procedures, views, functions, tables, schemas etc) into the project. It allows for all database objects to be stored in there (even database roles/users, certificates, keys etc).
Alternatively, you can use Visual Studio to import a database from a server. It will read your database and populate the project with all the objects from that database. It's very cool.
You can check in to TFS as you would with any other project which allows you to do versioning (with comments), attach that work to TFS tickets (if you manage your workload that way) and perform branching and merging and you can also compare different versions of the project or the project against already deployed versions.
Once you're happy with your database you can 'publish' your project up to a server of your choosing. This is a very useful method for creating code that can be deployed to multiple environments (i.e. different dev/test environments). You can also compare your project against a deployed version to see changes. For example, you could compare your project against a test environment to see what the differences are and generate a script to update the test environment to match source (or vice-versa).
SSDT is great for deployments because it calculates how to apply your database project (rather than just dropping the database and creating a new one). You can also use pre & post deployment scripts to work with data or add permissions onto your objects for example.
You can publish to a database/server, script or DACPAC (which is the format for copying your entire project/database schema and allows you to perform deployments/drift reports etc from outside of Visual Studio)
We're developing an aspx project with Visual Studio 2010 Professional, SQL Server 2008 R2 and Team Foundation Server 2010. Since the development is being carried out in multiple offices, each developer has their own local instances of the databases.
I want to bring these multiple databases under source control (or at least the schemas of the DB, structure and stored procedures - data doesn't matter to me). My preferred approach is to add database projects to the VS solution, which is already source controlled in TFS. Any changes will be distributed by TFS, and can be deployed locally.
The problem I'm having is that the database projects contain a reference to a local database instance (server & name). When someone gets the latest version of my changes, they will have a reference to my local DB instance (which is different to their local DB instance). They would need to change the DB details (thus checking the dbproj out) in order to get my updates.
So, is there any way that the database server & name can be left out of source control while the schemas remain under source control? Any help would be much appreciated!
I'm not sure if you can. However, you could use an alias, so all of the developers use a database on their local machine, but referenced by the same alias.
Take a look at: http://www.mssqltips.com/sqlservertip/1620/how-to-setup-and-use-a-sql-server-alias/ for how to set an alias up.
That way you can separate the database from the connection details.
I'm involved in developing a unique enforced database source control solution called DBmaestro TeamWork.
It has a plugin to SSMS which allows the developer to work directly on the database objects (change their working environment), run their tests and then perform Check-In which reads the metadata (tables' structure, procedures, functions, views etc.) to the version control repository.
With the Impact Analysis it is easy to merge changes from different databases to a single database.
The impact analysis algorithm perform 3-way analysis (not just a simple compare & sync) to identify changes origin from developerA which should not be reverted when developer merge his changes and it ignores the database name when running the impact analysis or generating the delta script.
I need to create an entirely new Sql Server 2008 database and want to use a Database Project in Visual Studio 2010 (Ultimate). I've created the project and added a table under the dbo schema.
The table .sql is shown only as plain text, though with colors. It has no designer, no Add Column, and no autocomplete. Existing column's properties are grayed out.
Usually, I use DB Project for nothing more than storing .sql files for source control purposes, but I'm assuming it can help me with designing the DB. Currently, it offers no such help and I think it's because I'm doing something wrong. Perhaps I need to deploy the DB to server first, or something of the such. I've looked for a Getting Started guide, but all guides I found start from importing an existing database.
Please help my understand what a DB Project can do for me and how.
Thanks,
Asaf
The whole idea of the VSTS DB is to get you set on the right path, ie. store database object definitions as .sql files, not as some fancy diagram. Any modification you do to the objects you do it by modifying the SQL definition. This way you get to do any modification to the objects, as permitted by the DDL syntax, as opposed to whatever the visual-designer-du-jour thinks you can and can't do. Not to mention the plethora of SQL code generation bugs associated with all designers out there.
The closes to a visual view is the Schema View, which shows tables, columns, indexes etc in a tree view and you can see the properties from there.
By focusing the development process and the Visual Studio project on the .sql source files, teams can cooperate on the database design using tried and tested source control methods (check-out/check-in, lock file, conflict detection and merge integration, branching etc).
the deliverable of a VSTS DB project is a the .dbschema file, which can be deployed on any server via the vsdbcmd tool. This is an intelligent deployment that does a a schema synchronization (merge of new object, modifies existing ones) and can detect and prevent data loss during deployment. By contrast, the 'classical' way of doing it (from VS Server eExplorer, or from SSMS) the deliverable was the MDF file itself, the database. This poses huge problems at deployment. The deployment of v1 is really smooth (just copy the MDF, done), but as soon as you want to release v1.1 you're stuck: you have a new MDF, but the production is running on its own MDF and does not want to replace it with yours, since it means data loss. Now you turn around and wish you have some sort of database schema version deployment story, and this is what VSTS DB does for you from day 0.
You might be better off downloading the SQL Server Management Studio for SQL Server 2008 Express - http://www.microsoft.com/downloads/details.aspx?FamilyId=C243A5AE-4BD1-4E3D-94B8-5A0F62BF7796
Using this tool you can create your database using the visual tools provided by that software. You can run your .sql script to build up the database and then visually adjust columns settings, table relationships, etc.
Once you have your database designed open up Visual Studio and open a connection to this database using the Server Explorer.
Visual Studio is ok for simple tweaks and changes to an existing database structure but for anything serious like making the database from scratch I would recommend using the Management Studio. It's free and built for that exact purpose :)