I am a new blogger. Basically an SQL Server DBA and performance tuning guy, I am also interested in poetry, literature and music. The aim of this blog is to express ideas as they come, on any of these topics i.e. SQL Server, poetry, literature and music. All are welcome to join me and express their ideas. The thoughts and ideas expressed in this blog are personal to the blogger alone and nobody need to take any offence to it.
I love MS SQL Server 2000 more than any version of SQL Server and over all other RDBMS's. It was a well made product, Performance wise and feature-wise it was a product in which every feature present worked well. I always feel that the people who developed it did it it with commitment and were very meritorious. It did not have too many bells and whistles but it worked much better than the so-called 'feature-rich' RDBMS's from any vendor. It is so important to hire well-qualified people, for e.g people with a four year bachelor degree in engineering/technology or higher from premier institutes and a good experience atleast in the technical field. Then the product they make or are asked to make would be competent and work efficiently.
These days, companies hire just about anybody based on a voluminous resume. The purpose is to save money because such people have to be paid less. In outsourcing scenarios, such people add to only to headcount and consequently to revenue of the contracted company. But what happens in the bargain is that although the assignment or the product may give results, it may not be efficient or robust. Making something and making something good are two different things. Companies get satisfied with making something and when experts start using these products after purchsing them, such products do not stand the test or pressures of production environments and the purchaser ends up hiring somebody else to make it better or purchasing higher and higher end hardware to make it work to his satisfaction. So in all, the customer loses his investment and gets poor returns. That is why it is so important to make a good product like SQL Server 2000. I remember a few years ago when I was running a poorly written code on SQL Server 7.0. It took around 13 minutes to get executed to completion. Then I ran the same lengthy query in SQL Server 2000. There was no difference in hardware or resource allocation between the two setups. The same query ran on SQL Server 2000 in 7 seconds. Of course I later optimized it and it ran in 00 seconds. But what my point here is that without any changes to code, SQL Server 2000 gave me drastic improvement out of the box with no inputs from my end. This is just one example. I have never seen something similar or other instances of performance improvement out of the box in any other version or RDBMS. Although my clients like to go to newer versions or switch RDBMS's and I participate in upgrades and migrations for them, I still feel that they should stick to a good database like SQL Server 2000 and not to get swayed by rhetoric, bells and whistles. In my opinion, nothing is greater than performance.
I had another client who felt he had an excellent 64-bit hardware and yet the performance was not upto mark. Somebody asked him to upgrade the hardware further and the nclient was not interested. Users of this website i.e. his customers had to wait 10 to 15 seconds on an average for responses. I took their top 10 SP's and optimized them. Each one of these SP's was called thousands of times a day. After optimization, testing and promoting these 10 optimized SP's to production, the total CPU utilization came down from 312 hours to 49 hours. This was in SQL Server 2000. The beauty of this product was that it gave you ample flexibility to code with your imagination only being the limiting factor. Not the same with other DB's though.
But now a days there are so many bells and whistles to RDBMS's that real T-SQL is getting drowned out. That is a sad state of affairs. T-SQL beats CLR in speed in almost all cases (except possibly string manipulation within variables) and yet nobody realises how important T-SQL is. In a good product, all other coding techniques should be part of T-SQL and NOT T-SQL being part of other methods. I again reiterate, simplicity, efficiency, flexibility and performance are more important than the cacophony that the bells and whistles make.
One more thing I like about SQL Server 2000 was the small learning curve. You learn quickly and then you use your imagination to bring out the best possible results. I have seen in some other RDBMS's that the learning curve is so involved and long and flexibiliy so little that the learners keep learning till the next version comes out and then start learning the next version without getting ample time to apply with imagination what they learnt. This is sad and ridiculous. Products should be made keeping the interests of the customer in mind and not keeping the limitations in thoughts of the architects in mind.
In my next post, we would look at some possibly cool coding in T-SQL. Bye for now.
