Failing to commit.... transactions that is: another example of poor understanding of the database

I got called in to a client’s office this morning. They were having an emergency. Their online processing system had come to a complete stop. Customers could not complete their orders. The first thing I did was take looks see at activity monitor. What did I see? About 40 – 50 batches being blocked by a single update statement that was wrapped in a transaction. I have seen more and more of this in the last 2 years. I believe the main problem is most people that do not work with databases as their primary job don’t respect them. What I mean by this is they don’t really understand how many of the features work. Indexing is a great example of this. How many .net developers really understand the concept of indexes? Not enough in my view. Yes while it is true that in most places there is trained Database professionals on staff that will handle all the day to day database tasks. However as a IT guy. I make it my business to know as much about the front end application tools as possible so I can better design the database backend. Those that read my arguments on guids as primary keys found here http://sqlserverexpert.blogspot.com/2009/03/guid-as-primary-key-conclusion.html
Know that one of my reasons was the benefits they had for the overall application design process.
I have many programmer buddies that as soon as there is a performance bottleneck right away it’s the databases fault. And this is true of us as well. How many times all of us have went in to a problem thinking “Those dam programmers buggered it up again”. We need to all work together and some of that responsibility belongs at the company level as well. I happen to work for a great company which believes you should know a little bit about everything so that you understand what your piece has to do, what it has to connect to, what kind of data is it going to receive etc. By doing this My Company is able to build extremely flexible systems for our clients; also we tend to bend the conventional rule book a bit. We do this because it is our belief that the system as a whole is being judged not its individual parts. My guid argument has a lot to do with this fact. Yes having a guid as a primary key has some drawbacks and yes it’s not going to be the most optimized database out there, but the system as a whole will be better because of it. Now this is just one example, all of our systems are different. The point I am trying to make is that we as IT people, not as .net coders’, DBAs, BI developers but all of us have a responsibility to our clients to make the best SYSTEM possible

Thoughts, comments, questions
mccannblogs@gmail.com
McCann Out!