Key/Value Attribute Hierarchy

This is something that just crossed my mind this morning: when working with values that fit nicely in a key/value attribute system, what do you do when you start needing more hierarchy?

I’m mostly just thinking out loud here, so bear with me.  Sometimes I find the cardboard programmer approach to be helpful.

Let’s take a fairly generic example.  Let’s suppose I am modelling a car – not in the physical sense, but int he behavioral sense.  So we start this off by deciding that each car part will have a set of attributes, and each attribute will have a value.  For example, a tire has a property called internalPressure, and it has a specific value, say 0.5.  If we were to represent this in a JSON object, it’d look something like:

    "internalPressure": 0.5

This works fine for our tire object.  But as we build more of the car, we run across another car part that also has an internalPressure property.  Our key is no longer unique enough to identify what our value is trying to say.  There’s two solutions here:

1. We could modify our key to make it more unique.
2. We could add some form of hierarchy.

For #1, it could look something like:

    "engineBlock_internalPressure": 19.3,
    "tire_internalPressure": 0.5

For #2, it might look like:

    "engineBlock": {
        "internalPressure": 19.3
    "tire": {
        "internalPressure": 0.5

Which of these two approaches is ‘right’?  Well that depends.

By making keys longer/more unique, you maintain a flat hierarchy.  If your data is stored in something like a hash table or a dictionary, this makes sense.  But maintaining those unique keys is also a bit of a pain in the butt.  What happens if you want to change what units you are storing your pressure values in?  If you need to select everything, how do you know that you’ve actually selected all parts that have an “internalPressure” property?  Basically, you’re relying in programmers following a difficult to enforce standard, which is always a bit of a scary practice.

By using a hierarchy, you do keep the ability to use the same keys in multiple places, which is convenient.  But you may also have to think differently about how you are storing those values.  Rather than just using a single hash table, you might have to have more of a tree structure, which may take more effort to search.

There’s always going to be some form of trade-off.  Depending on what you are trying to do, you want to pick the algorithm that is going to give you the benefits you want without having any drawbacks that you can’t deal with.  Sometimes it is as simple as choosing an existing algorithm, and sometimes you end up having to make your own solution cobbled together from various bits and pieces.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s