Karen: You mentioned that VSDB Pro would bridge the gap between database developers and app developers. How much of the gap is closed in V1?
Gert: First we're focusing on the database. In the future, we'll try to connect the app developer more with the database developer and make sure these two worlds can collaborate.
Richard: Some of that connection is in V1: You'll be able to define a solution that has both a C# project and a SQL Server database, and then you'll be able to deploy your application and the corresponding schemas that go with it. So it's partially there.
Karen: Will you support older versions of SQL Server?
Gert: Yes. But we distinguished SQL Server 2000 and 2005 projects because, of course, the types of objects are different. At TechEd, we supported only SQL Server 2000 objects because we had to limit our scope and that's the biggest audience, but we will fully support SQL Server 2005 by the time we ship. We're at CTP 3. Then there will be 4 and 5 and RTM, which is expected to ship by the end of this year.
Richard: With SQL Server 2000 being a subset of SQL Server 2005, it also builds us a very nice core for moving towards full [SQL Server 2005] support.
Karen: Will VSDB Pro support databases other than SQL Server?
Gert: This is all about SQL Server. It's not about other database vendors, but we are in VS.
Karen: How will customers purchase VSDB Pro? Will it be part of SQL Server?
Richard: We are a completely stand-alone SKU sold either separately or as part of the VS Team suite.
We don't plan to ship it with SQL Server. We do have a prerequisite of using an instance of SQL Server for internal validation within our project, and eventually you'll need SQL Server under the covers, but it'll be part of VSDB Pro and you won't have to buy a separate SQL Server license.
The Truth Is in the Project
Karen: How will a Data Dude work with VSDB Pro?
Gert: It all starts with a database project in VS. That approach facilitates the build-and-deploy metaphor because you build a project that puts out a .sql file, which you can then deploy towards the target.
Karen: So you no longer have to make changes directly to your database.
Gert: We're proposing one big mental change to the database developer: The truth is not inside your database, but the truth is inside your project. You will be able to take schema objects, build a project from them, and start working on the project. Out of the build, you'll get simply a .sql script that you can deploy to a database.
Karen: Can you create a project for an existing database?
Gert: We support two deployment scenarios: Start from scratch (i.e., a brand new installation), and incremental update (i.e., you have x, you need to go to y, and we'll build the difference for you).
Richard: We certainly will support an existing database because today the version of the truth is the database. We'll reverse engineer a database back into a project. Customers will start by creating a new database project, import their existing schema into the project from their existing database, and then work in our project system. From there, they move towards deployment to send updates out to their existing installations.
Karen: So what is a database project?
Richard: A project reflects a user database. If you had an application consisting of multiple user databases, you would have multiple database projects in a single solution. We explicitly made the decision not to make this hierarchy any deeper.
Gert: Today, a database project is merely a placeholder for a script file and a connection. With VSDB Pro, you can have scripts, but more important, we treat everything as objects. So a table is an object that has columns, constraints, indexes—all these aspects are editable, but so are versions. If you change a column name or add a constraint, that information is recorded in the version control system. We support whatever source control systems VS supports. In V1, we'll support change management for schemas.
Karen: How does your version tracking work?
Gert: Version tracking is nothing more than keeping track of all the changes in the underlying scripts inside a version control system. We treat the changes as text. We don't do anything funky. We made an explicit decision that every SQL Server tool should be able to consume the scripts that we have underneath. We don't want to divorce this from the use of existing tools. So people can still use Query Analyzer. You can integrate your project with VS Team Foundation Server for process or work-item tracking and version control, and then we have some basic reporting facilities in the schema.
Karen: Will this approach be foreign to Data Dudes?
Gert: At the end of the day, you're still working with a .sql file. We're not trying to build a new storage mechanism. We're trying to be as close as possible to what SQL Server has now. You can still use Query Analyzer and sqlcmd, but we're tracking changes inside the schema.
The big bet is that the truth is inside the project, not inside the database. So you can build a database project and reverse engineer something you already have. You can take multiple things and put them inside the project. You can start making changes to the objects.
Richard: And because the truth is in the file system, you can take a snapshot of the project, throw it on your laptop, work on it on the plane disconnected from your data center. When you come back, you can check in your changes, synch and resolve them, and do source control. So you no longer have only one guy at a time working on a live connection to your production or test server.
Prev. page
1
[2]
3
next page 
