Monday, July 11, 2011

The difference between urgency and importance

Are you constantly besieged with emergencies and don't know how to dig yourself out?

If so, I'll give you some insight as to how bring some sanity to your situation OR allow you to make a determination that your situation is in need of change. I'm borrowing some time management ideas from here as well as inspiration from a co-worker.

First, some clarification:

Importance refers to how much something will help you attain your personal or professional goals. So, for example, if you want to become a great guitar player, it would be important to acquire a guitar. It's very important to take an evaluation of all the tasks, commitments, and issues you are dealing with and determine how important they are. In the link above, it is a binary determination, something is either important... or it is not important. The simplicity of this formula has a certain appeal and to start with, I'd highly recommend it. An important additional note about importance is to use this factor as a determination of how much time you spend doing something. If it is important for you to be the best guitar player in the world... you shouldn't spend a lot of time doing other things, especially if you've decided those things are NOT important.

Urgency refers to how time sensitive some happens to be. Getting out of the way of a runaway truck is an urgent issue. Acquiring the guitar in the above situation is likely to become urgent if you are on your way to your guitar lesson and the instructor doesn't have a guitar for you to borrow. An important note on this regard is that the urgency of issues can often change due to outside forces, but the importance is relatively stable.

Now to the free advice (and worth every penny I'm sure):
Top left
Top Right
Bottom left
Bottom right

Thursday, July 7, 2011

Deciding on NOSQL vs RDMS

Anybody not living in a cave knows that NOSQL is a current hot topic amount technology solutions. One sadly missing piece is some sort of guide on how to determine if NOSQL or a more traditional RDBMS is a better solution.

To start with, I'll say you should assume that an RDBMS is probably the safest bet. Almost anything you can do with a document store can be done with an RDBMS, with the exception that it may not scale and/or perform as well as NOSQL solution. The big advantages of RDBMS solutions is that they have an enormous ecosystem of tools, documentation, and skilled administrators.

Given the above, why would anyone ever even look at a NOSQL solution? Here are a couple indicators that a NOSQL solution might be a better fit for your problem:

#1 You are storing simple key/value pairs. If your RDBMS "solution" ends up being a single table with a couple key fields and a CLOB with XML in it... you're probably using the wrong tool for the job.
#2 You are storing complex data structures that are non-relational. If you store hierarchal data structures that each "master" has different children on it, you're going to run into problems with an RDBMS.
#3 You need massive scaleability and distribution, and the economics of scaling are important to you. Many RDBMS solutions offer partitioning schemes that offer very good scalability, but the cost (licensing and runtime overhead) of that scalability is often an order of magnitude higher than with a NOSQL solution.