Before
Working on a project that includes a database implies dealing with the schema changes and versions. The problem is that the tools that can help you are pretty expensive and (from my experience) not 100% reliable. It was so bad that my team and I developed our own database versioning mechanism and even started working on a tool to automate it.
What I want
I want to be able to deal with the database schema objects the same way i deal with the code files – specifically, I want to be able to see a svn history for them.
I want to be able to deploy a new version of the database to test and production servers AUTOMATICALLY, without worrying about data loss.
I want to be able to restore an old backup (like one with specific test data) of the database and update it to the latest version.
I want to keep the developer, test and production databases in sync (that is, the schema is the same for the same version).
I want the configuration data (read-only data like states and cities) to be included in the versioning system. [more]
VS 2010 Database Projects
With the latest release of Visual Studio, Microsoft has finally added a functionality that was loooong overdue: REAL Database Projects.
There are some nice posts by Deborah Kurata covering the basics here: Introduction, Using an existing database, Adding tables, Building and Deployment, Adding stored procedures.
I tried the projects for a new database, added a few tables, and then imported a script for various objects from another database.
I was pleasantly surprised to see that everything worked as I expected – the extra objects were added without compromising the existing structure! 
For the next step, altering a table, I was a little baffled: should I edit the table on the development database and then compare the schemas, create a script and import it, or edit the CREATE TABLE in the sql file for the table?
The answer: any option would do! Of course, my favorite is the last, editing the sql file just like any code file. You can then get the changes script by comparing to another database (using a Schema Compare), or just hit “Deploy” and let Visual Studio deal with it!
So far so good
The scripts for the schema objects are maintained in individual files, so all you need to do is add them to your code repository and get object-level versioning!
Updating an existing database works like a charm (although I’ve only tried it with relative simple schemas so far). If you need manual touches, you can edit the changes script before deploying.
You can also add pre- and post- deployment scripts to handle your configuration data, for example.
My conclusion so far: Excellent work! What took you guys so long?!?
Nice!