Monthly Archives: September, 2010

SQL Saturday #52 in Denver

SQL Saturday has become a happening event and SQL Saturday #52 in Denver was no different.  Very well organized, good sponsors, excellent speakers.  I’ve been to three of them this year and I could say the same about each one.  There is a certain vibe at the events that I really enjoy, a type of sharing and discussion among professionals that many of us take pleasure in but don’t get to do enough.  It seems that when we are together on a Saturday, away from work and without the expectations that come from making a major financial outlay, we allow ourselves to experience the parts we like best about our business.  For most of us, our work is still a challenging mental exercise.  These events let our minds explore and allow us to theorize and hypothesize about the best way to implement a BI solution, or how to make SQL Server perform better, or what the best way to code T-SQL is.

If you haven’t attended one of these, do yourself a favor and take one Saturday out of the year to attend one in your area.  You don’t have to be a DBA to benefit either.  The people and sessions are far-reaching and cover anything from managing your career to predicting the future with data mining.

SQL Saturday #52 – Colorado September 25

Remember to go to SQL Saturday #52 in Denver, CO this Saturday.  It will be a great event with many excellent speakers, including locals Glenn Berry, Steve Jones, Kevin Cox and Chris Shaw.

Make sure and say hello if you see me there!

8 Core Principles of Data Warehouse Design – #4 Redundancy

Don’t be afraid of redundancy. As developers and database developers we try to reuse components and objects as much as possible. We try not to create two functions that do the same thing, and we try to model relational OLTP databases so that every data element is defined just once. Let go of this objective.

A data warehouse serves individual purposes, and everyone’s purpose. To make this happen with a non-redundant streamlined data model is very difficult. Data that needs to be measured transactionally may also need to be aggregated, and it may need point-in-time reporting capabilities. This could mean you store the same data three different ways. And that’s ok.