Instead of working, I blog.

This is the perfect topic to go along with what I wrote on my other blog today in The real difference between SQL Server and Oracle.

I just got an email from the producer of the new Kalen Delaney series on SQL Server giving me my press pass into the online content for this series. I've only watched the 1st 9mins so far and already it's exactly what I'm talking about in my other blog. Here's Kalen Delaney who writes one of the most successful series on SQL Server (the other one is by the late Ken Henderson. I still have a hard time saying that), and she's going the extra mile to put her book into a video training series where she explains the concepts herself.
I, like many other people learn better when things are explained to me than I do from a lifeless page. And Kalen's an experienced teacher so she has a way of explaining things that make you just get it. Already in this video she's already covered security of metadata and the sys schema. She's actually explaining how this stuff fits together from the ground up. That's how it's done. I have no doubt that the rest of the series will contain the same deep-level understanding.

I think I'm going to enjoy this series and I'll try to write-up a full report when I'm done. Or maybe I'll just do it as I go along.

OK, so here's the link to the site. You can order the DVD or you can watch it online. It's good stuff. Seriously, go check it out if you haven't.
I was recently chatting with Kalen in email and she told me that this is basically the course she teaches when she's brought into a company to teach a class.

Actually, I didn't mean this to be an official interview, but I'm going to go ahead and paste her email here. I'm sure she won't mind (at least I hope not) and she explains it better than I would anyway. I typically don't post emails without asking first, but she knows who I am and she answered my questions like she was being interviewed, so this one time I'm going to do it. But you'll almost never see me take this liberty.

1. What material will this first DVD cover…

You can get information about my course here: http://www.insidesqlserver.com/Course%20Description%20and%20Outline.htm
The first DVD covers most of what is in Module 1.

2. What format will it take… will be be a group of slides and whitepapers, or screencast instruction by you…

The DVD will be a mixture of live capture of me talking, and screen captures of my slides and my demos.


3. Who all is involved in the project…

I am recording the class that I have been presenting all over the world for the last several years. Chuck Boyce, of AskaSQLGuru.com is doing the filming and editing. The business side is being managed by Peter Ward of www.WardyIT.com in Brisbane, Australia


4. How often can we expect to see a new DVD come out…

Since I have to fly to New York for filming, we are only able to do about one a month. In fact, I am just about to leave for the airport for the second round of filming.


5. What advantage will one have in ordering these over just getting the books…

Different people learn in different ways. If you like to hear and see someone explaining concepts, this can add to the benefit of the books. People pay a lot of money to attend my classes, but since I’m only one person, I can’t offer them that often. The DVDs are a chance to for anyone, anywhere to get to take my class. If you can read and absorb everything in the books on your own, the DVDs might not offer anything more.

So again, here's the link to SQLServerDVD.com.

I've had to call a vendor for support and it's already not going well. I'm not going to say which vendor, but I'll tell you that I'm having problems with my SQL backups.
Anyway, I went online and filled out the form with all the info... OS, SQL version, etc... then I got the email from the support tech asking me for all this info.

I replied by saying I had already filled that stuff out when I created the ticket so why did I have to do it again? I don't mean to be a difficult customer, but come on. Why do I have to do everything twice?

Every morning when I leave the house I get in the car and the first thing I do is throw my jellied toast face down in the floor of my car. Why not, that's where it's going to end up anyway when the asshole in front of me slams on his breaks. Now at least it doens't piss me off when it happens. Then when I get to work the first thing I do is run some kind of wild query that fills up all the memory and CPU and locks everyone out of the system. Why not, that's what's going to happen as soon as my favorite report writer logs in.

Some days it just doesn't pay to get out of bed and go through the hassle. Then again, if you've done what you should as a DBA, it shouldn't be that bad. Hopefully you've setup things in your DB that keep things from getting too out of hand. Hopefully you've been able to teach your report writer some basic dos and don'ts (sp?).
But what if you're in a new place? Can you still be effective? Of course you can. Again, if you're a good DBA you've collected a nice gaggle of scripts that you take from place to place. Years ago when I was just getting started, I didn't get that. I always thought, why be lazy, just write the damn scripts when you need them. But that's the wrong attitude. It's not laziness, it's practicality. There's just no reason to work out that logic every time.

So if you follow some of your own best practices and set yourself up for success, maybe you can withstand the bad times. But there's nothing you can do about traffic, so I guess you'll have to keep throwing your toast on the floor. Life goes on.

For those of you who follow my blog, you know that I've used LiteSpeed for many years now. And one of the things that's always bugged me is the lousy way they run their upgrades. To upgrade LS typically consists of having to do some version of manually deleting the current repository tables and then running the install program. And this is after uninstalling your previous version manually as well. And if you want to save your data in your repo tables you have to create new ones and copy the data over, or just rename the old tables. And it still isn't that easy because of the relationships. If you just rename the tables you have to rename the relationships too or the new install will fail. And you have to do this for every box you own. What a pain in the ass!!

Well, I have a problem with LS not backing up one of my DBs even though it's been working just fine for almost 2yrs. So I just upgraded from v.4.7 to the latest 4.8 (yes, I know v.5 is coming out soon, but I can't wait). And let me tell you this... it looks like they finally got these upgrade problems fixed. My upgrade went smooth. I didn't have to manually uninstall the old version, I didn't have to play my usual shell game with the repo tables, and I didn't have to burp the service. Life is good.

Now, I'll have to see if it actually fixed my problem. But I'm happy to be able to report something good about LS for the first time in a long time. They've mostly been adding features, and very slowly at that, and haven't been really concerned with our actual problems. Maybe this is a turning point.

Anyway, good job LS guys.

One thing that's as varied as ways to code is how to manage the code itself. Or I guess I should say architect instead of manage, but it all comes down to management.

The 2 major ways are to componentize and to not. And by componentize, I mean taking all the individual components and turning them into small independent chunks that can be called from many sources. A good example is taking a date calculator routine in your SPs and turning it into a function so the SPs just call it instead.
So those are the 2 ways. You either put it inline with the code or you make it into a component and call it from all the modules you need.

Of course, I'm mainly talking about SQL code here, but it really applies to any kind of code I suppose.

It's easy to see the advantages of developing a component solution. This is the DB equivalent of COM, right? But what's not easy to see is what it does for you (or to you) support-wise. What this solution can do is put you in a new form of .dll hell from the old days.

Let's take a simple example...
Let's say that you have sn SP in prod that's giving you problems and you want to track down where the degraded performance is coming from. So you open up the SP and start looking at the code. You see that a major component of it is an external SP call. OK, so you open up that SP. Now you see that that SP calls 3 other SPs. And each one of them is calling more SPs. And so on and so on. This is the definition of spaghetti code isn't it?

I'm actually in the middle of doing this very thing right now. I wanted to stop and blog about it while I was still pissed off. I've been doing this for an hour now and I'm not any closer to a solution than I was when I started. So you can see that while going the COM route can be helpful, you can take it too far. And that's really what happens, isn't it? Devs take a good idea and drive it into the ground until it's so hard to manage it's not even worth having it anymore.

I've been trying to come up with some guidelines for this and it's tough. But roughly, I like to say that if several SPs use the same code, or are calculating the same thing, it's ok to pull out into COM. The same goes with code that gets changed a lot. If you've got code that changes often and is used in a lot of SPs, by all means put it into it's own SP so you only have one place to change it.

Anyway, I guess I'll get back to my plate of spaghetti now.