Guest Editorial from Phil Factor
I recently had to draw up a list of 'top ten' pieces of advice for programmers who were starting out as database developers. It is a difficult thing to do when one is immersed in the study of the intricacies and detail of the plumbing of SQL Server. I've always considered this sort of list to be the province of journalists and trainers. I was therefore chewing the pencil a bit when this nugget popped into my brain.
'Don't develop an application on a development server with less data or throughput than the maximum projected for your production database.'
I can't get away with that one, I thought. Everybody seems to cut a database with just a light dollop of data here and there. Few people bother with doing simulated loads during development. For me, the more data and simulations I have, the happier I am.
My attitude changed after working on a large database. It all started with one of those calls that happen too seldom for my liking, and it was a while ago, I'll admit. 'Available for work? Good Grief, no; I'm up to my eyes in ....How Much? Per year? Per Month! When do I start?' It was a cash-rich company in big trouble. It was offering cheap international phone calls that undercut the monopolistic multinational Telecommunications companies. Business was booming to a point where the initial systems were completely swamped. They couldn't even bill their customers.
This was so long ago that it was in the days when I believed I understood SQL Server. Tackling this monster was an uncomfortable awakening. SQL Server changes its characteristics somewhat, when given a hundred million rows or more. Even the daily data import was more than a million rows. Rollbacks could take almost a day. If you got your indexing strategy seriously wrong and the 'optimizer' decided on a table-scan, you waited ages. SQL Server 7 behaved like a thoroughbred stallion in a thunderstorm. If you showed fear, or made a mistake, you got thrown. If you calmed it down, treated it right and pointed it in the right direction, it almost flew, bless it. For me it was a painful lesson in humility, and a great education. There is a world of difference in creating a small fast database and a large fast database. If you think that you can postpone the final design, and wade in to do a swift refactoring as the system grows, then you may be in for a horrid shock.
If your production system is going to have a particular size and throughput, then surely you either have to develop it with at least that size and throughput, or make a wild guess that your design will scale up. I know which I'd rather do.
The Voice of the DBA Podcasts
The podcast feeds are now available at sqlservercentral.mevio.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.
Overall RSS Feed:
or now on iTunes!
Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.
