See Also: Main Page - Business Intelligence - Data Mining the StackOverflow Database
Now for some schema notes, and I'm going to go out of alphabetical order because everything links back to the Users table. I'm only going to cover the fields that aren't immediately obvious:
In StackOverflow, questions and answers are both considered posts.
StackOverflow limits you to five tags per question (answers aren't tagged), and all five are stored in this field. For example, for question 305223, the Tags field is "<offtopic><fun><not-programming-related><jon-skeet>". It's up to you to normalize these. Sam Saffron's SoSlow utility automatically creates Tags and PostsTags tables to normalize these.
Next, check the contents of the Tag field carefully. StackOverflow allows periods in the tag, like the .NET tag and ASP.NET tag. However, in the database, these are stored as "aspûnet". Just something to be aware of.
This stores the votes cast on posts, but the key field is VoteTypeId. All of the Id fields except for Badges.Id are from StackOverflow's original database. In theory, these numbers will not change, which means if you build your own child table structures like UserBaconPreferences, and you join via User.Id, you should be able to blow away and reload the Users table with every new StackOverflow database dump. That's the theory, but in reality, you shouldn't rely on anybody else's ID fields, because there's no reason to believe these won't completely change down the road. Who knows - Jeff might switch over to GUIDs as primary keys.
This joins to Votes based on the Id field. Common vote types include: