I hang my head, and I feel shame.

Wow. My last post was when? Scott Hanselman posts 18 times per day, while in Africa, and I haven't posted since August?

I hang my head, and I feel shame.

Well, in my own defense, I have spent a great deal of time over the last four months looking at the inside of airports. Ever been to Denver International? It's gorgeous. Kansas City International? Exceptionally functional. Not pretty, but it works, and it works well.

Continuing my, series, here are a few more myths about SharePoint I'd like to burn down.

#3 You shouldn't have a content database larger than 50GB

People have misinterpreted a lot of guidance on this topic over the years. Implying that SharePoint shouldn't have a database larger than X size implies that there is some pre-determined upper bound to the size of a SQL Server database, which just isn't so. A SharePoint content database can scale to whatever size your SQL Server infrastructure can support, which means that if you've got some crazy 64 processor SQL Server with 512GB of RAM, you can have yourself a big ole' honkin' content database.

Now, before everyone starts building out huge SQL Server infrastructures, let's take a close look at that SLA you agreed to. You know, the one that says you'll be able to restore the system within four hours of an outage? Now, go talk to your storage management people. What do they say about how they are backing up your databases? Mirror SAN? Same building? Going to tape?

The deal with content database size is all about the rapidity with which you can recover the database. Personally, I'm nothing but happy if I can keep the database to 50GB or less. Normally, this is very achievable with a sufficiently developed site taxonomy - but more on that later.

More to come - and this time, you won't have to wait four months. I hope. :)