Today we have a guest editorial as Steve is on vacation.
Like many others, I read the page on MSDN Maximum Capacity Specifications for SQL Server with a low whistle of amazement. 524,272 terabytes? 253 foreign key references per table? 2,100 parameters for a stored procedure? Could anyone be getting anywhere near those limits?
I get to hear about, and sometimes come across, some enormous SQL Server databases. I’ve worked on, and occasionally designed, a few myself. It has left me with a deep respect for the way that SQL Server copes, and the amount of work that is required to create and maintain a database system that can handle large amounts of data. I hope, therefore I can be forgiven a smile when a hopeful startup announces a new database system to rival the behemoths of the database industry, or when someone refers to a database as ‘Big Data’ when it would even fit in a spreadsheet.
The databases I’ve dealt with are dwarfed by the titans that I’ve heard about through talking to colleagues at PASS or reading about in forums. Sometimes, I come across them by accident. I once wrote a routine that automatically converted the deprecated Rules and Defaults into constraints. I tested it out on what I thought were some fairly large databases. I then got a complaint from someone who used it that the routine was much too slow. I blinked in wonderment. I hadn’t even bothered to optimise it since it ran in a twinkling of an eye. I should have guessed that it wouldn’t scale well when faced with a database with 60,000 tables. Fortunately, he fixed it to work fine with that sort of size of database. I couldn’t help wondering how SSMS would cope with a database that size!
For various reasons, we don’t get to hear about all those huge SQL Server databases that work well. Which industry has the biggest systems, in terms of sheer volume, or in processing power? What are the types of database that scale easily, and what special techniques are required? I’d be fascinated to hear from people running really big databases successfully with SQL Server.
