I Am Curt

(Update: This entry was backfilled by a later entry – Many To Many Is Not Physicial – to buttress its logic.)

In Many To Many Has Utility, we talked about how Many To Many better represents how people think about things.  Because of this, people have an instinctive bias towards Many To Many approaches.  However, because our physical surroundings are so hierarchical, we can rapidly run into problems.

Let’s take another look at my file cabinet, and that frustrating home escrow statement.  I want to put my statement in two different folders, and I just can’t.

To try and solve this, it’s been suggested to me a few times that I could make a copy of it, and store copies in both places.

By making copies, we have, in a sense, converted a Many To One relationship into a Many To Many relationship: a folder can contain Many files, but a file can also now be in Many folders.  Problem solved, right?

Well, what if I want to update one of the files?  Perhaps it is an invoice that I want to mark “PAID”.  If I pull out one of the invoices and mark it paid, it doesn’t automatically mark the other one.  It’s just a copy.  It’s not literally the same document in two places.  If I were to pull the other copy out later and think it wasn’t paid yet, I might double-pay.  This is of course a contrived example, but in the real world, it can lead to all sorts of larger problems.  Generally speaking, if you update one copy, you want the other copy to be updated as well, automatically.  Unfortunately, it’s impossible to do this in the physical world.

Another similar problem is if you want to remove the file.  You would have to remember every single location of the file and all its copies, to be sure it was fully “deleted” from your file cabinet.  Whereas if it were truly one file stored in multiple places, you would only have to delete it once.

These kinds of synchronization problems are common in the real world, and it’s because people are unwittingly trying to simulate Many To Many relationships, within a physical structure that doesn’t support it.  When we thought we were creating a Many To Many relationship in my file cabinet, we were actually just creating a new Many To One relationship – duplicating information and increasing maintenance costs.

As a result, people often abandon Many To Many as an organizational approach, concluding that it’s more hassle than it’s worth.  But in fact, the problem isn’t with Many To Many itself.  The problem comes from trying to graft it onto physical items.

As we discussed in Hierarchies Are Overrated, people are conditioned by the physical world and its hierarchical structures.  But because we are instinctively drawn towards Many-To-Many thinking, this can cause confusion.  We’re conflicted about how to represent our thoughts.  And since we can easily give up on Many To Many as an approach, a misunderstanding develops about Many To Many, leading to a lack of awareness about its benefits.