IT:AD:Data:Db/Projects:HowTo:A Quick Intro

Create a new Db Project:

After that, the usual reaction is …wow. It’s not a db…and what ever it is – it’s big! What am I supposed to do?!?

Relax. The reality is that SQL Server can manage very complex and powerful scenarios.

Guess what…you probably don’t. So close all that off, take a deep breath, and start small.

Just one Table to start with…

Well, if you were in SQL Server Manager, you probably would start off with creating a table.

A table is…a dbo schema object, so burrow down, and find the Tables leaf, rick-click it, in order to add a new table:

And it shows a dialog where you can name the table:

And finally shows you a dialog where you can type in the DDL that defines the table:

BAM! And that’s about where 90% of dev’s spit a dummie with something akin to the following:

“Holy Cr…ow! Like this is any easier than using SQL Server Manager (which was already about as intuitive as a kick in the head)?!? I said know some SQL, not the ins and outs of every little SQL DDL thingie…!??!

I

sn’t there anything easier than this?!?”

Right clicking the table name and select “View Obejct in Schema View”:

which pops open the Schema View, where you edit the field in a more visual way:

It’s not 100% as easy as SQL Manager, but you get the hang of it pretty quickly.

So the big question is…why trouble myself with learning anything new? Why not just stick with SQL Server Manager?

The Answer is simple: change tracking.

By treating your db not as a binary, but as a script, you can version control your database precisely. You get to see in your favorite diff viewer exactly what has changed.

And the script, in readable format, rather than an opaque binary, becomes the single point of authority on Db schema.

Hope that inspires you to go take a look at them.

Note that if your are in a shop that likes EF4 or any other ORM, it still is perfectly possible to develop a pattern of import/update to keep everything in sync.