SQL

I Suck!

Blog Author — Wed, 07 Jul 2004 03:41:00 GMT

Yeah, yeah, I'm sorry I've been negelecting you my lovely reader. There's just a whole lot to play with at the moment, just got a reasonably priced Video Camera, my lovely bike, been playing with VS.NET 2005 Beta 1, getting a new deployment (and tracking down a deadlock) on this site and finally playing with Adobe Premiere Pro - which is just awesome, if you've been stuck with Windows Movie Maker, try a real editing package!
Whew...as well as that I've been looking into SQL Hierarchies using something called 'Nested Sets' by Joe Celko - this really is the best way I've seen of doing hierarchies (well, trees) in SQL. Also ordered his book on the subject Joe Celko's Trees and Hierarchies in SQL for Smarties ...so, with all of that I have to get back to this site. I was very aware that I was just metablogging for a while there which I personally can't stand. So,l no promises but I'll try and get back to things as soon as I can!

UPDATE: Ooh, this is a pretty complex subject and really pretty interesting. There's a couple of other links I can recommend this site has the most complete set of links to the best methods of modelling hiearchical data in T-SQL, this site has a really nice method for supporting Nested Sets in a basically 'automatic' way. There's a whole lot to learn about this topic (much of which is mentioned in the book I mentioned earlier) and articles like this on the 'Nested Interval' model look really useful but will take a bit of work to figure out. Luckily the system I'm developing is fairly loosely coupled in it's Schema, allowing me to easily upgrade the hierarchical model I use if necessary...

Yukon presentation - it rules!

Blog Author — Tue, 25 Nov 2003 13:23:00 GMT

Just been catching up on the PDC presentations, came across this one on Yukon, also, for an interesting perspective on why you should use SPs in Sql Server, watch the first 10 minutes! Man, I am so looking foward to Yukon reaching RTM; the architectures which this thing enables will be so elegant.

UPDATE: As Jon Galloway pointed out, these are pretty buggy; the UI takes a bit of getting used to (or sucks to an incredible degree would be more accurate) - hint, don't click on the images for each track, click on the text. Worth persevering though!

Now this really bugs me...

Blog Author — Sun, 23 Nov 2003 01:12:00 GMT

Noticed a link in my referrer log from this post which comments on a comment I made in the whole Dyanmic SQL debate, this comment:

Right. Because evaluating arguments based on their validity is too much work, so it's much easier to pick the "winner" by picking the side with the least vested interest. It apparently has nothing to do with the fact that Frans is, well, correct?

Based on my comment taken out of context from this post:

"To be honest I'm always a bit reticent to pay much credence to an argument on an approach to Data Access from someone who has a vested interest."

Sorry, but I did not 'pick a winner' I said in the same post that I took no absolute position in this debate, for the most part I disagreed with Frans's position because I did not agree with many of his arguments, the vested interest comment was based on this by Frans-

"A good O/R mapper helps you with this. Microsoft also believes stored procedures are over: Microsoft's next generation business framework MBF is based on Objectspaces, which generates SQL on the fly. ".

So his position seemed to be boiling down to the belief that you should use an O/R mapper (such as of course, LLBLGen Pro), it was also positing the belief that Microsoft had the belief that this was also true (Objectspaces is ONE approach, Yukon actually increases the utility of Stored procedures by allowing the use of cLR code within them) , in addition I made several comments; and replied to a comment from Frans here on my own site which did challenge the validity or his argument - is it too much work to read ALL the comments?
My initial comment boiled down to the fact that if you have a strong vested interest in any position on any topic, it is likely that your arguments will be slanted to one position over the other, I love pizza so if someone asks what 'the best' food is, I'm going to argue for Pizza. If you also read further into the comments - and Rob Howard's folow up comments - the validity of Frans's argument is challenged alot! What these comments on my post seem to come down to is that this guy agrees with Frans's position, didn't bother checking the 'facts' presented and therefore chose to take task with my position because he didn't agree with it...fine!

SQLJunkies...fine, fine blogging site

Blog Author — Fri, 21 Nov 2003 06:10:00 GMT

The SqlJunkies weblog site is really starting to fill out, it's fantastic to have so many SQL experts posting in one place! Oh, and I'm not just saying that because I agree with Donny Mack's views on SPs; well, partially, reporting is still a pain but I had discovered a good link to a version using the SP to generate the Dynamic SQL which seemed like a sound approach.

Stored Procedures versus Dynamic SQL - the old debate...Frans Bouma's take...

Blog Author — Wed, 19 Nov 2003 01:12:00 GMT

Frans Bouma really doesn't see the point of using Stored Procedures over using Dynamic SQL - so Frans, what's your take on such things as Indexed Views and User Defined Functions - which are essentially SPs but there's no equivalent for Dynamic SQL, so you're suggesting I should not use these any more?
To be honest I'm always a bit reticent to pay much credence to an argument on an approach to Data Access from someone who has a vested interest (I know LLBLGen Pro supports SPs but it does have a strong bias towards Dynamically Generated T-SQL), kinda like MS on the Linux debate...slight vested interest (or former Halliburton CEO on Iraq - but that's a different matter :-))
I do use SPs almost exclusively for Data access, I have no vested interest in one approach or the other, I used to use Dynamic SQL in the bad old days of ASP/VBScript but switched to SPs when I needed more oomph in my data access code. I have a strong preference for manipulating data using Set based logic, yes, for more complex operations I'll bring the data into code but in general, I use the DB for manipulating and then return the smallest amount of data back to code. The reason I do this isn't stubbornness, simply I find it easier to filter and composite my data closest to it's source.
I also find some of Frans's arguments a bit lacking, there is an argument for using Dynamic SQL where you have to react to user input for filtering data; reports are a classic example where you might want to find matching data items based on a variable number of inputs - by all means use Dynamic SQL for that, but in 90% of cases I just want to pull data from a DB as quickly and painlessly as possible this is where I'd use SPs. I often use Table variables for compositing and filtering data, treating SPs as set providers and modifying the eventual output resultset to contain only the data I actually need - this would usually require multiple trips to and from the DB (we're talking in the dozens here for each instance) and would be pretty slow, as well as causing heavy network traffic which I can usually ill afford in highly scalable sites.
In short what I'm saying is that for my purposes, the 90% Stored Procedures, 10% Dynamic SQL works best - making absolute statements about such things is like commenting on religion, politics or Open Source or Java - I don't believe there is a completely binary argument to be made in any of these areas, there's too many entrenched views - horses for courses is my opinion :-)

Run .NET code from Sql Server - before Yukon!

Blog Author — Wed, 15 Oct 2003 00:25:00 GMT

Found this on Ashutosh Nilkanth's blog (good name!), basically allows you to run pretty much any CLR code using a Sql Server extended stored procedure - not nearly as good as Yukon, but if you need to do this now, it is a start!

SQL Server 2000 Indexed Views

Blog Author — Thu, 18 Sep 2003 05:15:00 GMT

Though I'd point to an excellent article on Indexed Views. For those who don't know what these are, well, if you have a fairly complex database schema, you can gain a great deal of performance benefits by aggregating the output of common queries into indexed views. Unlike normal views, these are authomatically updated when the underlying data changes (normal views are pretty much just running another query when you call them). They're best suited when you perform frequent queries on relatively static underlying data (kind of a database level cache)...