Re: Code in the database or middle tier (the CLR controversy)

Serge Rielau wrote:
> DA Morgan wrote:
> > William Stacey [MVP] wrote:
> >
> >> But your talking design now. That has nothing to do with SQLCLR
> >> integration. I don't see the DB design process changing just because
> >> of SQLCLR. You will still have DBAs/ DB architects doing that work
> >> (or should). The app guys are still going to be the app guys. You
> >> need both. So nothing has changed in that regard.

This isn't a new concept or untested technology. Oracle and DB2 have supported Java database plug-ins (e.g., UDFs, stored procedures) since the late '90s (DB2 UDB ver 5.1 and Oracle 8.1.4).

> If you take a look at the procedural constructs of each of these SQL
> "extensions" you can mess things up equally fine as with VB, Java or C#.
> .. Do they write better SQL because they use PL/SQL?

If there was a pattern of systemic failures, database corruption or security problems due to database extensions written in a programming language, Oracle and IBM would know by now. There have been several major releases since Java in the database emerged in 1997.

If allowing non-SQL database extensions were a serious product design flaw, we'd see IBM, Oracle, Sybase and Microsoft taking a different tack. They've embraced the Java VM and .NET CLR because they provide better server stability than older technology, such as writing extended stored procedures in C.

The potential for harm isn't so much a question of which tool to use as who should be doing the work. It's obvious you should not use someone to develop VB, C# or Java database extensions if he/she isn't normally trusted with production database work, such as creating stored procedures with PL/SQL or T-SQL.

The guideline I've expressed for eight years about Java in the database applies also to the CLR issue:

"When it comes to developing SQL database extensions, it's better to take a database person and teach him/her Java then to to assign the task to someone who knows Java but lacks database expertise."

The same applies to working with the CLR for extending databases, whether they're DB2, Oracle or Microsoft SQL Server. Don't use Java, VB or C# skills as the primary basis for deciding who's writing database extensions.

Ken North

http://www.SQLSummit.com
http://www.GridSummit.com
http://www.WebServicesSummit.com