Agile Database Development

Agile development at MSFT and tid bits about VSTE for DB Pros

This Blog

About
Email

Syndication

Search

Interesting Musings

Photos and Screen Shots

Product and Team Pictures

To Table Design or Not To Table Design

As we have built the TSData story the focus has been around a SQL script experience because the current "designer tools" in VS: Tables, Queries, Databse, are all built for a connected experience, connect to a database modify it, see what happens. Our product is about changing this to a work disconnected, work against code, manage change with version control, have tools that help you understand the impact of your changes etc.

However, we realize that the designer tools do provide a good amount of productivity and are desired. The question at this point is does not having Table Designer really block your ability to use this tool? IE if we were to delay the product launch beyond the planned by the end of the year to add table designer would it be worth it? Or would you rather get the prdocut basically like it exists now with us completing the existing functionality and closing bugs and shipped ontime? Then start on V2 and build really solid data modeling, table design, etc. My natural inclination is to lean towards get the release done and out, stay the incremental agile approach not the just throw one more feature on the bus.

Published Wednesday, July 12, 2006 11:59 AM by thomas murphy

Comments

# re: To Table Design or Not To Table Design @ Wednesday, July 12, 2006 4:03 PM

Not having a table designer is fine with me. I probably wouldn't use it if there was one since I prefer plain old DDL.

+1 for EOY Launch.

bryant

# re: To Table Design or Not To Table Design @ Wednesday, July 12, 2006 6:57 PM

I am torn on this one - I believe a designer is key long term for the success of the tool (if nothing else to bring it up to par with other similar tools), but I can see the usefulness of releasing the capability as is (i.e. there is enough value there to warrant it) and then moving forward with the designer idea.

My one problem is that if V2 is a year away and that is when I get the designers then you aren't really agile and I can make the argument to put the designers on the bus because the next time the bus comes around is a long time from now.

HintonBR

# re: To Table Design or Not To Table Design @ Wednesday, July 12, 2006 7:22 PM

Hi Thomas...

Designers are welcome, but particularly, the majority of time I use scripts, because I think it's most practical.

In my opnion, you don't need to delay the launch because of designers. If there are some feature that I would accept a delay, this feature is Intellisense for T-SQL Scripting. Also I can't understad why this was removed from SQL Server 2005, and what's against implementing it. Most Oracle GUIs do have "Intellisense" variations, and also there are thirdy party tools that include that tool. I just wanted it to be embbeded directly into the tool. Designers can wait, give us the Intellisense and grow our script wrinting productivity!!!

Regards,
Rafa®

Rafs®

# re: To Table Design or Not To Table Design @ Thursday, July 13, 2006 9:10 AM

My vote is to get the release done and out. Table designers are nice, but I don't think it warrants delaying the ship date. I think it's more important to round out features of scripting a database upgrade/install over creating new UI tools.

bdouglass

# re: To Table Design or Not To Table Design @ Thursday, July 13, 2006 9:15 AM

I believe this would be a show stopper for us. In fact, I sent a message about this to the Database Pro folks on the MSDN forums. I've installed CTP 4 and was very surprised that I have to do so much 'raw' editing of my schema objects. For example, say I want to add a field to a table, a constraint on that field, a FK and an index. I have to go into each respective schema folder and add all this by hand. Not exactly state of the art. Very tedious, time consuming and error prone.

A major problem I have with waiting until V2 is when will V2 come out - 2008?

Amos Soma

# re: To Table Design or Not To Table Design @ Thursday, July 13, 2006 9:54 AM

Don't delay the product. yes, I would love to have designers, and I hope they will be in the next version, but this version is going to add to much to Team System, and be helpful to so many people right out of the gate, that it does not need to be delayed.

mickey_gousset

# VSTS Links - 7/13/2006 @ Thursday, July 13, 2006 10:41 AM

Thomas Murphy on To Table Design or Not To Table Design.

Rob Caron on stpBA StoryBoarding for Team...

Team System News

# re: To Table Design or Not To Table Design @ Thursday, July 13, 2006 12:02 PM

IMHO a Designer is a big thing.

That is the primary feature of ERWin that I really use and one that saves me tons of brain cycles. When designing a data model I've found I work best when I can see it. Print it out, mark it up, walk through its implementation and usage, etc, etc. That's harder to do with scripted SQL (though after a bit you don't see the SQL, you see the blond, red-head, ... ;)

Also when returning to a project after a bit of time, having a visual model helps me remember the relationships and lessens the re-learning curve.

It helps when documenting the DB, etc, etc, etc.

If a Designer were built-in, then I could dump ERWin (and Visio's data model template). This would increase the its value a great deal.

Now the question as to delay or not...

I say No, don't delay.

Lock V1 down, get it right as is and out the door (i.e. don't feature creep V1). Don't include a half-assed Designer in V1 as it might turn people off or give a bad impression of the entire product (even though it's only one feature of it).

Include a solid and complete Designer in V2. Do it then and do it right (but don't take too long to do it please).

Thanks for asking this question and giving us the chance to comment on it... :)

gduncan411

# re: To Table Design or Not To Table Design @ Thursday, July 13, 2006 1:51 PM

I'd certainly like a designer. But I suppose it's better to ship it earlier and just make us get the syntax committed to our brain (tables are easy, I just don't happen to write constraints and indexes and so on often).

MichaelGiagnocavo

Anonymous comments are disabled