4 Answers
4

Jeff and Jarrod posted self-deprecating answers, but as an outsider, let me tell you that the database code and schema are really tight. (And I should add that has absolutely nothing to do with me, hahaha.) If you're going to scale a SQL Server database fast to a large audience at a low cost, you don't want any extraneous business logic in the database. No triggers, no UDFs, no CLR code, no record-by-record operations.

Normally when I do performance tuning for clients, I start tracing queries with a duration of more than 10 seconds. At Stack Overflow, I have to crank my filters down to 150-200 ms just to see any activity. It always gives me a grin.

Just generally speaking, application servers are cheap, and SQL Server is expensive ($5k-$25k per CPU). Even if you use open source databases, it's easier to scale application servers than it is to scale database servers. Every added web/application server is relatively easy to implement with a load balancer - every added database server, not so much. Every time you have to do anything even remotely CPU-related, do it in the web/application tier, not the database tier.

Jeff: Let's see the latest feature.Me/Dalgas: Here you go!Jeff: What is that? I don't know what that's supposed to be..Me/Dalgas: Isn't that what you wanted?Jeff: But there's no words on it..Me/Dalgas: Want us to redo it?Jeff: No.. no time.. we'll do it live - DO IT LIVE.