A continuation of my blog from yesterday regarding Sql Saturday 89.
The first session that I decided to attend was Database Makeover: Renovate your Data Model given by Audrey Hammonds (Twitter:@Datachix2). This session focused on how to Identify, Prioritize, Plan and Sell the need to fix an inherited data model (Or one you made a mistake on). The take aways that I took from this were:
- Having Multiple Implicit or Explicit Data type conversions in a query may indicate you have the data type of a column wrong. Immediately I thought of a table that I’ve made this mistake in. While all of the data is an Integer (Area Codes), I use the column as a string 99% of the time. I’ve already (2 days in) started to formulate how to change this. Fortunately it’s in a very low level lookup table, so the change shouldn’t take a great amount of work.
- Store Data once, and refer to it. This one isn’t one that I’m “guilty” of (At least not often), but its always nice to hear that the things that you preach, other’s believe in! Sometimes being the only database guy in a company full of “Do it fast”, instead of always “Do it right” makes you the lone voice of “Hey! This isn’t optimal”.
- Data Storage and laws impacting how it’s stored. This one is a bit outside of my day to day thought process, usually I store the data in the most efficient format for later retrieval, going to have to do some serious research, and try and figure out how the different states that we do business in, might impact our liability here. We have a strategy meeting to plan out 2012 coming up in a few weeks, this will definitely be on the Agenda.
- After you Refactor your tables – trust yourself and remove the old columns that you “don’t need” anymore. This is something there is opportunity in for me. Well to be honest with both myself, and you; I SUCK at this part. I’ll refactor the tables, get the storage up and functioning, move all the places that point to that data, but then be too scared to drop the columns. No Longer. As of this weekend that changes. Get rid of them if you don’t need them!
- Abstracting the developer / users from caring WHERE the data is stored. This is a big one for me, and one that I’ve been working on getting better at over the last 6 months. We all preach communication, and openness, but sometimes it’s better to just “fix” something, make all the needed changes and move on. As long as all of the Development teams object calls continue to function in exactly the same way (or better), does it matter where the data is stored?
Admittedly I was a bit nervous about attending my first SQL Saturday, all of my SQL Server knowledge is self taught, and learned through extensive effort on my part, as well as a lot of logical thought processes. Leaving my first session I was much less nervous, I knew more then some people in the room, less then others, and more importantly I left the first session knowing just a bit more then when I entered.
Overall – A great start to the day, a little learning, a bit more self confidence. On to the next session!