Otey on Stinger Vs. Yukon and the Art of War.
Sun Tzu writes in The Art of War: "A defeated army first seeks to do battle, then obtains conditions for victory." It's amazing how true this really is. Adam points us at an op-ed piece that Michael Otey has written comparing DB/2 "Stinger" to SQL Server 2005 with respect to CLR integration. While I don't know that I'd blame the apparent brain damage shown by these poster(s) on Java, it really does seem like they have an agenda themselves, rushed into battle then tried create conditions where they might be seen as being "right." Here's what I posted back as comments:
Frankly I don't get what the anonymous bitching is about here. Sounds like somebody else has a vested agenda to me.
On the "its only beta, its only beta" chatter: I wouldn't be one bit "shocked" if there more total installed instances of the beta product than there are production versions of DB/2 Stinger. I'd say that makes it pretty darned real. An TPC benchmarks? Are you kidding me? Go look at the TPC-W where it really matters: Price to Perf. Where's DB/2 on that list? *Hint*: there's a reason that business *choose* SQL Server: It's called making financial sense!
But let's look at some things that the article has to say...
Paragraph #1: Michael's point here is pretty clear: DB/2 had CLR support before SQL Server did but SQL Server 2005 does things *different* than DB/2 does. No more, no less. Advantage: push, I think. Being first doesn't mean being best.
Paragraph #2 main points: DB/2 only supports invocation of the runtime from stored procedures; SQL Server supports that and more like functions, type, aggregators and triggers. Advantage SQL Server. DB/2 supports the current version of Visual Studio.NET, where as if you need a GUI for SQL Server, you really want to use the also-beta Studio 2005. I'd call that an slight advantage for DB/2, at least today. Regardless, you can use SDK and any tool you like -- including WebSphere, Eclipse and SharpDevelop -- to do your coding.
Paragraph #3 main point: DB/2 calls the CLR out-of-process, SQL Server calls it in-process. The advantages of the in-proc call are obvious to anybody that's ever thought about it. Funny that for all the complaints registered here, you've got nothing to say about the that. Advantage SQL Server.
Paragraph #4 main point is that while DB/2 supports the invocation of the CLR, it stops there. No tracing, no visual debugging. SQL Server supports those things and you'd better believe they're important to both developers and DBAs. Huge advantage SQL Server.
Paragraph #5 main point: Michael feels Microsoft made their support for *better* than DB/2 did theirs in a number of ways. Pretty hard to argue against that. For all your complaining, you didn't even bother to try to either. Can you?
Finally, just because you don't like the message, trying to kill the messenger strikes me as sign of just how biased you really are. Had you done a little bit of research, you could have easily found out that TEAC has such extensive experience working with the IBM platform (since at least 1996) that the actually ship products that make it easier to work with. You'd also find out that he was writing great books about programming (ISBN 0962874337) with the AS/400 platform as far back as 1993.
And you?
Sounds more like you've got an Axe to grind than valid criticism of the article or the product.