In software design, especially database design, you sometimes come across hierarchical relationships like a folder containing files, or a department containing other departments, or any other relationship where the hierarchical order or who contains who is important.

Let’s take an example. You’re the programmer using a web content system where there are folders and these folders have a many-to-many relationship to each other (meaning any folder can contain any other folder, even itself).

Unfortunately you’re tasked with placing a lot of folders inside other folders programmatically (no support from the UI, and by the way, your time budget doesn’t allow f-ing around with the UI to try to figure this one out… “it should be simple to do”, your manager says and give you very little time…)

How not to do it

Here are some examples of database table design (or rather column names) that will likely end up forcing you to redo the job and use 4 times as many hours:

• objectID, referenceObjectID
• connectedFrom, connectedTo
• id, relatedId
• topId, bottomId

Yeah yeah yeah, seeing that mess, you should definitely create a test connection to see what means what.

But what if you display the folders in the UI with components like “List connected from objects” and “List connected to objects”.

Looks good, right, we have two lists and one list can contain only one item and maybe that list can even be designed to look like it’s only one object.

Until someone else connects another object in “the wrong way” and suddenly that nice looking one-object display goes scrolling, swelling, wrapping and overflowing the whole UI.

Or hey, this being a many-to-many-relationship after all, maybe your UI can handle it just fine…

How about your users? How about the support staff?

How about the assumptions of other programmers about what contains what, or what is located where?

I mean, sure, it could be hilarious. A system where the employers can fire their boss or at least lower their wages, or where Texas is located in Austin, or you don’t eat hamburger, but hamburger eat you… like in Soviet Russia…

The ONLY way to do it

There is ONLY one way to describe a hierarchical relationship between two objects in a way nobody can misunderstand ever:

• parent
• child

Now, for sure, if you have problems with parent-child relationships, don’t take it out on your software, take it up with your therapist.

This. Is. The. Only. Way.

Before, after, left, right, center, above, below, alpha, beta, lalala, isn’t going to cut it.

But what if…

No what-ifs.

Parent.

Child.

Period.