Browsing articles from "December, 2013"

To Santa with Love, Kitty

Dec 24, 2013   //   by Karen Lopez   //   Data, Data Modeling, Fun, NoSQL, Snark  //  2 Comments

Dear Santa,

My friend and debate foe victim Thomas LaRock ( blog | @sqlrockstar) sent you some last minute gift advice for organizations who need your help.  That got me thinking, so I made a list, too.  I checked it three times because I’m thorough like that. I’ve based this list on observations and data I’ve collected over the last year.  Much like you do.  Except I didn’t use that creepy shelf elf guy.  

Just in case you didn’t collect enough data, or it got lost in some hard drive failure:

For Twitter: A way to restore those 20k Tweets of mine they lost a few years ago.  Oh, wait…probably better that they aren’t part of the firehose any more.


For Data Modeling tool vendors: A copy of my multi-volume set of enhancement requests for supporting new database and datastore types. It’s nearly 2014; it’s time we data architects were able to do our job regardless of the target technology.


For the NoSQL Community: A love of data so strong that they can tolerate the mere mention of relational database solutions when appropriate.


For Microsoft: A brilliant new name for Windows Azure SQL Database. I can’t keep saying that in my presentations.  Even WASD is difficult. 


For Oracle, IBM, and Sybase users: A community as active and helpful on social media as those in the SQL community.


For United Airlines: A set of laminated copies for each employee of your Star Alliance agreement to remind you that 125k flyers do indeed get perks on your airline. First World Problems, I know.


For Star Alliance airlines, including Air Canada: A "Wifi in the Sky for Dummies" book. Tell them to get cracking.


For NASA: That other half a penny.


For Justin Bieber: US citizenship and a ranch in SoCal.  And a plane ticket.  No monkeys.


For Rob Ford:  NULL.  Not even coal.


For my readers and their customers: A year in which their data is much loved, in the right place, at the right time, with the right granularity and the right integrity.  Or World Peace.  Probably easier.



(Kitty is my Starbucks name.  I figure Santa knows that already.)

Your Christmas Cookies Can Teach You About Data: Sugar Cookies


I don’t do a lot of baking. My kitchen is mostly the place where I blend my breakfast and enable my caffeine addiction. But my family has a tradition of making dozens and dozens of cookies every holiday season. Sugar cookies, No Bake Cookies, Snickerdoodles…the list just goes on and on.

As I was looking in my pantry for ingredients this year, I started thinking about how the process of producing cookies was a lot like data architectures. I may have been drinking. I’m pretty sure of it, actually. A lot. I mean I’m a lot sure I might have been drinking. A lot.

This week I bring to you a short series about Christmas Cookies and data.

Sugar Cookies

Yum! Probably the most common version of Christmas cookie is the decorated, cut out sugar cookies. Recipe books, blogs and food network shows make them look so easy. They contain just a few simple ingredients (butter, sugar, flour, salt, vanilla, eggs) that form the basis of almost all other higher forms of cookies.

What makes these special is what you do with that dough. The most exciting versions have you to roll out the dough, cut it out with cute cookie cutters, bake, cool, then decorate them. It’s just cutters and icing, right?

The Big Lie

I’m here to tell you that it’s all a lie. First, unless you have a lot of practice, the dough never rolls out cleanly because a whole lot of things have to go right first. Then you cut them out and they fall apart or tear. You’ll end up burning the first few batches until you know how your oven heats and how your baking pans work.  Maybe you need at Silpat liner. Or parchment paper.  Or an actual baker.

But no amount of equipment prepares you for the disaster of decorating them. They NEVER come out like the pictures. Those cookies on blogs and in recipe books are probably made by specialist magical cookie elves who spent their 10,000 hours learning to make cookies from Betty Crocker herself.  With Photoshop. I’m pretty sure every decorated cookie recipe is shopped worse than a Ralph Lauren model.

There are all kinds of warnings in the recipes: let the cookies cool on a rack. But who has time for that? Be agile and decorate them while the cookies are still in the cooling sprint. Oh. Crap. What the heck happened? If you haven’t spent a lot of time doing some test and training baking, your first set of cookies are going to be an embarrassment.

Burnt Cookie by Flare -

Silver Balls, Silver Balls…

And did you know that those little silver and gold balls that are the key part of the most beautiful cookies ARE NOT SUPPOSED TO BE EATEN? It says so right there on the label, “To be used as a decoration, not as a confection”. I bet you didn’t even RTFML. You’ve been unintentionally poisoning your kids and grandpa for decades. Or maybe intentionally. I won’t ask.

Silver Balls with warning (c) Karen Lopez

Lessons Learned

What does this teach us about data?

  1. Recipes make everything look easy. A lot of people see the recipe books and assume that making these cookies is very easy. And yet it’s difficult to get them right. The dough needs to be the right temperature and have the right ratio of ingredients to make the dough the right consistency. This requires not just a recipe, but a lot of practice.  It also requires good technique, the right tools and the right environmental factors.

    The same thing applies to data architecture. Sure, one can watch a 45 minute presentation on what all those boxes and lines are, but until they have applied the principles then lived with the results of their practice designs, they won’t really understand why one cannot just use melted butter or leave out the baking soda because it’s easier. It takes a lot of experience to be a good architect. Just like it takes a lot of experience to make beautiful decorated cookies.

  2. Demos of data modeling and design tools make everything look a lot easier than they are in real life. Part of this is because demos take time to give and they have to deal with the easy case. Sure you can migrate a database from Oracle to SQL Server by running a wizard. But you might not like the database or the data that comes out the other end. In fact, I can guarantee it you won’t. Migrating from one infrastructure to another always requires analysis, design, and implementation expertise. Decisions, even. Tools are never a substitute for design.
  3. If you are an amateur, you’re going to make a lot of mistakes. Heck, even professionals will make mistakes. But amateurs are going to make more.  It’s how it works.  You make mistakes, learn from them, get better. You’re going to burn a lot of data, and therefore users and ultimately customers.  You can read all the recipes in the world and watch all the episodes of Iron Chef, but living with the results of your design decisions is what helps you learn. It’s okay to make a lot of mistakes if you are learning in a class. Or are working on a development project iteration.

    Production, though, is like learning to cook your first meal for Christmas dinner for a close family of 20-30 people. It doesn’t scale well and you’ll just end up disappointing everyone in a big way. Heck, you might even kill some people with your bad design.  You might have some letters after your name, but until you get to the professional level, don’t call yourself a chef.  Well, you can, but your customers aren’t going to trust you after the second batch.

  4. You need to read and learn. Warning labels are a good start. The great think about most data principles is that they haven’t changed a lot. The technologies have, but not the foundations.  If you don’t read and learn, you won’t be in a position to deal with change that is coming whether you want it or not.
  5. Some ingredients for data actually don’t really help the data. Comma delimited data in a column is fast. It allows people to go around the whole data governance process. Stuffing internal-only customer data in to AddressLineFour is fine, right? Until someone prints that on the envelope and mails it to the customer. Sure, these cute workarounds are shiny and happy. You need to be able to see when people are proposing the equivalent of shiny silver balls. They are pretty, but not for use in real life. You can quote me on that.

There are probably a lot more lessons to be learned from Sugar Cookies, but I just wanted to cover the basics. Just like the ingredients for Sugar Cookies.

10 Tips for the Minimalist DBA

Dec 3, 2013   //   by Karen Lopez   //   Blog, Data, Database, DLBlog, SQL Server  //  4 Comments

Title Slide Minimalist DBA

It seems that there’s so much to learn when you are first working as a production DBA.  What do you focus on first?  How should you prioritize your learning? What things should you automate and measure?  What skills are core to your job, no matter how long you’ve been a DBA.  These are the things that we think that all production DBAs need to know and continue to build upon.

In our DBA Fundamentals presentation on The Minimalist Guide to Database Administration, Thomas LaRock ( blog | @sqlrockstar )and I (@datachick)  discussed the core skills one should have when filling a DBA role. That presentation has been recorded (I will update here when it is posted).  I hope you were able to join us or will stop by and watch the recording.

10 Tips for the Minimalist DBA

  1. Protecting your data is your number one job.  I’m betting that no one else in the company has a to-do list to protect the company’s data.  Maybe someone at the strategic level, but not to actually ensure it’s available when it needs to be.  That means your first job is to ensure backups and recovery are working.  Test your backups, test your restores.  The first thing I do on new projects is to ask about the backup and recovery configurations.  I once found that the production system had not been backed up for more than five years, even though everyone else thought it was backed up daily.  Don’t just ask.  Go look.
  2. Don’t waste time alerting yourself of things that don’t require a reaction.  You may be tempted to set up alerts so that you get an email and a text message to notify you every time a backup successfully completes.  Or when your online monitor finds your database upright and smiling.  However, that soon leads to alert blindness.  You will miss the real alerts that you need to do something about.  Hard drive getting full? Response times approaching ice age times?  Those are things you’ll need to be ready to deal with.
  3. The best DBA is a lazy DBA.  Not a sleepy DBA, but a DBA that automates as much as you can. Think of this as a Driven, Lazy DBA (DLDBA). Do you have tasks that take 15 minutes to do, require no human decisions and that you have to do multiple times a week? Those are automation candidates.  Be lazy so that you can spend your already overscheduled time on tasks that need your awesome data professional skills.
  4. You can’t manage what you don’t measure.  If you don’t know it exists, or whether it is still up and running, you will be stuck in a perpetual firefighting mode.  Tom thinks that firefighters would make great DBAs, but that doesn’t mean that great DBAs are in 24/7 firefighting mode.  It’s also good to understand what’s the best way to measure these things. Almost all measurement consumes resources.  Do you understand what make sense for each case?
  5. You need to understand the basics of all kinds of things.  Always be learning and looking forward. Just because we picked a few things to focus on doesn’t mean you can ignore all the rest.  You need to build your basic literacy of things that aren’t your primary responsibility.  Storage basics, database design methods and practices, web services, development tools and methods…yes, there’s a lot.  Start with the things that are causing your databases the most pain and work out from there.  It’s sometimes a bit overwhelming when you attend a conference or pick up a book and realize how much you just don’t know enough about.  In fact, there’s a name for this: the Dunning-Kruger effect.  The more you know, the more realize how much you don’t know.  The only way to deal with this is to always be learning and looking forward.  Sure, there are some people making RAID-loads of money supporting COBOL and IMS systems, but overall staying afraid of new technologies like cloud, NoSQL, BI, and big data is going to keep you blissfully ignorant.
  6. You must practice everything while your database isn’t burning. It’s not enough to watch a one hour presentation on how backups and restores work.  It’s not enough to download a script.  You need to get in-depth, hands-on experience doing these things. Not just a one time in a class thing, but practice with real world situations and data.  You need to schedule that time to do this. And your boss needs to support this.  Then you need to practice with intentional errors.  What happens when the time on the server is messed up?  What happens when you don’t have the right log files?  What do you do if the SAN is down?  Where are your restore procedures and checklists documented?  You don’t want to be “learning on the job” when your PHB boss is standing beside you and there’s smoke coming out of the server.
  7. Writing stuff down is good. It’s Agile even. The Agile software method calls for the right amount of documentation.  Many read this as “no documentation”, but they are wrong. Yes, sometimes to you can just walk over and ask the person who set up the job why they did something, but on my projects that person has moved on to 6 more teams since I last saw him.  I recommend using wikis or SharePoint collaboration areas for these things, so that they are all in the same place and can be accessed with any device.  By the way, do you know if your documentation is backed up? Redundantly available?  Restores aren’t just for databases.
  8. The more you install, the more you have to manage and troubleshoot. Install only what you need.  Of course, that may mean looking a bit forward for planned uses, but there’s no need to install everything “just in case”. You might even want to look at Server Core as an option, since it has a tiny footprint, requires less management and you can still use your remote GUI tools to manage it.
  9. Don’t be the one that panics. Practice and documentation mitigate stress and panic.  This is where all your laziness, planning, testing and learning pay off.  You’ve seen the guy that sits in front of a server, rapidly pulling cables, pushing buttons, running scripts and wizards and has no idea that he’s making things worse.  Don’t be that guy.  The more calm you are, the better job you’ll do.  And the more calm everyone else will be.
  10. Empathy is a highly-valued trait. For users, for other data professionals, for everyone. Empathy isn’t sympathy or feeling bad for others.  It’s about understanding what their pain points are and why they feel the way they do.  If you can reflect that empathy, work will be easier and progress towards a common goal can be made.  If you come at all issues with a zero-sum game approach, you’re going to have issues getting in the way of doing your job.

We also listed these links as great places to find more information about these skills or to practice them:

What advice did you wish you’d had years ago?   What else should a minimalist DBA know about?

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to by Email