When first exposed to SharePoint, many a newbie thinks, "Ah, so SharePoint has this content database thingie. So to start developing on the SharePoint platform, I need to learn how to run queries against this database, right?"

This idea dies rapidly once the SPNewbie dives into the SDK (and the SharePoint community). The object model has its kinks, but is much cleaner to work with than straight SQL queries. Ditto for SharePoint's built-in web services.

And sooner or later, the fledgling SPGuru will see this dire warning, oft-repeated in the SDK itself:

Modifying the database schema or database structures is not supported. Changes that you make to the database contents may be overwritten when you install updates or service packs for Windows SharePoint Services, or when you upgrade an installation to the next product version.

Because of this, some SharePointers come to treat the content database as a black box, never to be touched (much less understood).

That's a shame. The warning is worded strongly, as it should be. But don't overreact — if you read the warning thoroughly, you'll notice that it doesn't forbid you from just looking at your data on the SQL side.

There are some very useful things you can do using SQL queries against the content database. And some of these things are impossible (or at least difficult) using the object model, web services, and/or good old stsadm.exe. Besides, to be able to utilitize SharePoint (or any platform, for that matter) to its full potential, you have to really understand how it works under the hood.

So dive in to the databases — look at the schemas, build and run some SELECT queries. The database tables are documented in the SDK, after all.

Standard disclaimer: Always run your queries in a test environment first! Anything that updates your data (as opposed to simply querying it) shouldn't be done lightly, if at all. Adding your own triggers, views, and stored procedures is even more risky (and not supported by MS). A good rule of thumb: look, but don't touch (unless you really know what you're doing). But the whole point of this post is: don't be afraid to look!

In some future posts, I'll show you some SELECT statements that I've found useful (mostly from an administrator's point-of-view).