I have something that I need to get off my chest. I realize that this is a season of elevated rhetoric and political positioning, but why must our (what I used to believe) respected technology journalists bury themselves further and further into the muck? Everyone is entitled to their opinion, and thus their political views. No question there. But why should I, as an avid reader and subscriber to technology blogs and sites, be subjected to the very PERSONAL political rantings of writers who, according to their own "about me" blurbs, are writing to cover TECHNOLOGY and related issues, not politics, or how stupid Bush is, or what Kerry's Vietnam record has to do with the price of eggs?
Now, if the blog or site is more broad with respect to subject matter, and the blogger or publisher of the site wants to rant and rave about their pet peeves, then I say more power to them. Or if the particular political issue at hand has some impact or potential impact on our industry, then, again, I say, you go boy! And I do recognize that people can say whatever the hell they want on a site that is owned and operated by them. But I think it has gone WAY too far.
I call out the following well respected and talented journalists and ask them to back away from the constant political commentary:
Dave Winer, Dan Gillmor
Both of these writers have plenty of amazing subject matter to discuss, and regularly do so on their blogs. But recently, their postings have been edging closer and closer to 50% or more political opinion pieces, and less and less about the technology and the business of technology that drove me to read them in the first place. Now, some might say, "What a hypocrite, that's exactly what you're doing! What does this rant have to do with SQL Server?" The difference is that this is the only outlet I have available to me to express this opinion.
I just read an interesting DevX article that got me thinking about the new features in SQL Server 2005 that will allow managed code in stored procedures. A. Russell Jones discusses the pros and cons of what will certainly continue to be a hotly debated topic. His arguments center around what developers will demand and what development managers will want as well - they are not always the same thing.
I know that in my shop, what the developers “want“ rarely enters into the equation. It's all about what solves the business problem most effectively. As I've explained to many a pissed off developer over time, the best technology solution to a problem is rarely also the best business solution as well. If it were, we'd all be using Lotus Notes as our email and groupware solution, and we'd have moved to OS/2 back in the days when Windows 95 was still floundering around.
So, this certainly applies to the question of using .NET managed code in stored procedures as well. The issue is - what is going to solve the given business problem most effectively. T-SQL is pretty damn good at doing what it was intended to do, namely performing set-based CRUD operations on relational data. It's not particularly strong in looping or control-of-flow or calling outside libraries/methods/functions, but that's not what it was designed to be strong in. So if those things are essential to solving your business problem you may want to look hard at CLR-based stored procedures. If they're not, then there's nothing wrong with sticking to T-SQL, no matter how “cool“ or “fast” or “3l33t” the developers may think it would be to do otherwise.
Jones makes some unsubstantiated assertions about performance gains in using CLR-based procs over T-SQL. I'd like to see if there are any definitive tests that have been conducted, and under what circumstances. Properly tuned queries in T-SQL are pretty hard to beat, I would think. If anyone has done any testing or experimentation in this area, I'd love to hear about it.
I've been in a philosophical debate this past week (mostly with myself) about the merits of “fixing it when it ain't broken” so to speak. As with any shop that makes serious production use of SQL Server, over time you develop a large quantity of business logic in stored procedures, UDFs and the data-access layer code (in whatever form that may be) that calls them. And unless you've got just a small number of developers, who communicate with each other constantly, you are bound to end up with a mix of different coding styles and ways of doing things.
So I've been looking over this mess of stored procedures, which is working perfectly, and wondering what can / should / will be done about it. Here's a typical scenario:
- App A calls SP 1, which in turn calls SP 2 and SP 3 to complete its transaction.
- App B calls SP 2, which in turn calls SP 3 to complete its transaction.
- App C calls SP 4, which is nothing but an empty shell that calls SP 1 to do the actual work.
When App A gets retired, is it appropriate to move the functionality of SP 1, SP 2 and SP3 into SP 4? The only way to figure out if apps other than A are calling SP 1 is to run Profiler, which I have asked to have done. If it turns out that there are no other apps using SP 1, should it be dropped once its guts are moved into SP 4, or should App C be modified to simply call SP 1 instead? Or should I do nothing? My head hurts.
The operations folks are asking, appropriately, why do anything since any part of this is going to cause SOME potential disruption at worst, and at best be a pain in the butt. The architect and designer in me says “it's lousy spaghetti code and it needs to be fixed”. And “it's only going to get worse if we don't clean up after ourselves constantly when applications are retired or modified”. My feeling is if we don't do it now, we'll never do it. Is that the legacy I want to leave to whoever comes along after me? Oh, so it's all about ME after all, huh?
I love my job. Really.
I had an interesting conversation with Microsoft today about a little-known feature in Windows 2003 Server called Authorization Manager (AzMan for short). I stumbled across this application completely by accident, while attending a seminar that I really had no business attending (I was just there for the free copy of MS Office 2003 Pro :-). But anyway ..... AzMan is essentially a graphical tool for managing role-based permissions and for scripting business rules as part of those roles. It interfaces directly with AD, so that you can use AD groups as part of the definitions of your roles.
In my shop, we built something custom to do this about a year ago, and it's not very well integrated with AD. So I was looking at this from the perspective of where MS is taking it in the future, so that I could make an intelligent choice as to whether or not I should continue to develop our own solution, or move over to AzMan. I've looked at the classes that are available in the .NET Framework, and those apparently will continue to be enhanced through Whidbey and beyond. But MS is going to rewrite the AzMan tool itself as managed code, as it current is a COM application written in C. This should be available in the Longhorn timeframe, so it's quite a ways off, although in the first beta they're hoping to have a stable AzMan running under the Framework.
Anyway, you may want to look at what's available now. I need to make some decisions on moving forward with it as is, or waiting. What we have now works just fine, but I really don't feel like making any more changes or improvements to it knowing that MS is doing the hard work on this for me.
This article is another example of what's wrong with the (over)buzz around Yukon. First of all, data access is not the only thing that middle tier components are used for. Thus the article could be very confusing to the uninitiated. Second, it oversimplifies the issue. We use a set of middle tier components to do all of our XSLT work, because transforms create a significant drain on web server resources. So pulling the XML out of the database is just the first step - then you have to do something with it, right?
So the XML datatype in Yukon, which is awesome, is one tool in the toolkit, but in my mind does not reduce or eliminate the need for middle-tier applications to do their fair share of the heavy lifting. XML in and of itself is mostly useless on a web site unless transformed into HTML or some other format.
I've also yet to be convinced that just because you can store XML in your database, that it's the right thing to do in all situations. I think it all depends on what front-end applications are going to make use of that data, and whether or not you have that transform layer in place.
Don is right on the money with his rant, but it's not just Microsoft that's causing the problem. It's the trade press too. Microsoft can hardly be blamed (well, ok, they can be blamed a little) for their technology “pre-pre-pre-views” - after all that's what marketing is all about. But the press does not have to jump on every bandwagon that comes along. The so-called industry experts that write for the magazines and online pubs that we all read should know better and start adding some value (many do, but many don't as well) rather than just repeating what the vendors say in their press releases. Oh, that's right, I forgot, Microsoft advertises heavily in most if not all of those sites and mags. Nevermind.
For example, here's an opinion piece that I came across last week that really ticked me off. Can someone tell me what exactly was the point of that? This guy obviously does not do any hands-on development or integration work with SQL Server himself, or he never would have written this. Here's my response to it, which was a little bitchy, but I couldn't help it.
What I like in terms of future prep is something more like this from Itzik Ben-Gan. This kind of article actually helps me prepare for the future, rather than simply raising more questions than it answers.
I'm always amazed at just how much there is going on in the SQL Server community, not to mention the .NET community as a whole. Right now I am working on a number of projects, some including SQL Server design and architecture work, some not. One of the things I'm doing is trying out the Microsoft SQL Server 2000 Best Practices Analyzer as part of some consulting work I'm doing for another business unit within the company. It's not a bad tool, and certainly saves you from having to dig up all that detail by hand, particularly if you are analyzing multiple servers at once. I just wish it had some reporting options other than “Purge Report” and “Print Report” .... like maybe “Save”?
I also really took to heart the link from a month back or so posted by Don Kiely. It got me thinking and I've been digging around a lot more lately in vendor database applications, just amazed at the crap I am finding. If the quality of a system's database design truly is an indicator of the quality of the system overall, and I believe that it is, we're in trouble. My company is currently piloting a system that is priced in the 7-figure range, and I've had an opportunity to dig into the DB schema, although not the system code itself. Quite possibly the worst database design I've ever seen in almost 10 years of working with and around MS SQL Server.
Anyhoo ... glad to be a part of this community.