I did a lot of writing in 2010. Unfortunately, I didn't do a good job of keeping all of that writing equally distributed throughout all of the channels where I'm active. So here are a few more posts from my blog, put on-line during the months of November and December 2010, that I didn't get posted here on SQLBlog.com: 1. It's Time to ...

Good grief, there's a lot of travel in my future. <sigh ... deep breath> It'll be exhausting and it'll be hard to lose so much time with the family. But if I'm able to avoid travel mishaps, it'll be fun.  Meet Me In St. Louis I'll be speaking in St. Louis, MO on Tuesday, September 14th for their mid-day meeting. The details, ...

I'm speaking tonight on Top 10 Mistakes DBAs Make at the Atlanta SQL Server User Group meeting in Alpharetta, GA.  You can find all of the details here.The Best Dang Design Book for SQL Server Professionals - EVER!I thought I'd liven things up a bit with a little contest.  The rules are simple: A. If you don't follow me on ...

The final numbered post in this version of my “pillar” series of posts ends in the most contestable part of the design/implementation process.  Encapsulation. The concept of encapsulation is not contested (or even contestable by sane programmers in any field of the art of system creation. Every time you use a Windows API call you are ...

A bit of terminology that gets beaten to death is that of the “physical” database.  I would think most every DBA uses this term (I do), but…to mean what?  I think there are two common utilizations: The layer of tables, constraints, indexes, etc used to store data The actual on-disk structures. Frankly, until 3 years ago, I ...

With the previous post on the fourth pillar, I have reached the “end” of the design posts.  To review, these were: Coherent – cohesive, comprehendible, standards based, names/datatypes all make sense, needs little documentation Normal – normalized as much as possible without harming usability/performance (based on testing) ...

This blog probably won’t stir up a hornet’s nest or anything, but I would also expect that it would be the least popular in practice. The person who feels they can disagree with the need for a reasonable amount of documentation is probably nuts. In the first post, I defined documented as “Anything that cannot be gathered from the previous four is ...

Okay, so on the first look this sounds like the most boring Japanese action movie ever. Requirements is tearing through the village, and Architecture is in the city.  Developers by the horde are trying to code both of these into oblivion…Maybe not.  Clearly I am talking about something a little more exciting…the battle between the forces ...

This one should be simple to anyone who sees it (once I decode what I mean by fundamentally… and sound…by then for sure!) In the initial post I defined this as – fundamental rules enforced such that you don’t have to check datatypes, base domains, relationships, etc.  The gist here is that you at a minimum don’t have to spend all of your time ...

The first pillar was easy, since no reasonable person is going to argue that having a design that is not coherent is desirable. No matter what the type of system, any design that isn’t easy to understand is likely to be a bad design (obvious caveats are that it must be understandable to other people of a given level of intelligence in the given ...