Data Dude Extensibility – How IBM integrated DB2 into Visual Studio

I am sitting in a room at Tech Ed 208 with about 15 people who got up early enough for this session. I am blown away there aren’t more people in here, but I guess the after-party at Universal Studios last night kept people in bed late this morning. This session is a joint presentation by Gert Drapers (the actual Data Dude) and Brent Gross the from IBM for the DB2 integration project team.

It is clear (and stated) that other RDBMS vendors will follow suit as MS has provided a fundamentally pluggable model for vendors to integrate their DBs into Visual Studio with a provider model. Can you smell Oracle, boys and girls? I can. Gert is being vague about who they are working with. MySQL will be cool.

There are several levels of extensibility:

• DB Provider
• This is the actual connectivity to your own RDBMS. This provider is responsible for talking to the VS model layer for the DB project and translating between your DB and the model.
• VS Features
• The ability to alter features in Visual Studio, like:
• Refactorings available for a given provider.
• Syntax highlighting
• language formatting rules for reverse engineering operations
• Static analysis rules for your particular SQL language
• Yes, you get static analysis rules for TSQL. This is the death clock for select * from …
• Static analysis in BD2 SQL may be different than that in MS TSQL
• You can write your own static analysis rules in .Net by inheriting from the provided Rule class or *yeah* implementing an interface (are we hearing a theme out of MS?) I suppose if your company were anal enough, you could actually implement your proprietary naming convention rules as static analysis rules. Gert actually did this is an demo by writing a rule that checked column names to ensure they were in Pascal case. Neato. The funny part is when some of the developers in the room started telling him how his demo code could be refactored. Lol.
• Model Extensibility
• VS actually works against a model of the data store and lets the provider do the translation.
• Using the model paradigm for DB development provides full round trip model to implementation support for any given DB.
• Gert actually showed a little command line app that looked at a Northwind DB in Access and a different Northwind DB in SQL Server and compared them. There would be very different SQL syntaxes if we were simply comparing creation scripts. The DBs showed as the same. More accurately, the models checked as the same. Cool.
• So, I could script the process of taking a DB2 database and migrating it to SQL Server, or visa versa, in this model paradigm.

This session signaled several things to me.

1. MS products really are being designed with extensibility and integration in mind. No really, this time.
2. The Data Dude model of working with databases has genuine merit. The days of SSMS (SQL Server Management Studio) and the Query Analyzer fan base are numbered. Treating DBAs as developers really is a better model.
3. Something different is occurring at MS with the changing of the guard.