How Data Structuring is like Coffee
If you’re anything like me, a nice, hot cup of coffee is a great way to start the day. And, there’s nothing quite like a cup of single origin Kenyan coffee. But, what makes this coffee better than my $1 bodega cup? After all, it doesn’t come with a side of friendly bodega cat.
One of the primary differentiating properties is the coffee is single origin, and what does that mean? Simply put, the coffee comes from one place. Benefits to this are coffee cherries/beans are grown, harvested, and processed on location by the farmer and a relationship and trust is built with the farmer and family. Good for the company, good for the farmer, and good for taste buds.
Okay, okay. Coffee, farmers, cats? What does ANY of this have to do data structure? Much like data, coffee is better if the details about the coffee come from ONE place, a Single Source of Truth.
Single Source of Truth(SSoT) is a data structuring and storage principle in which information is stored in and called on from one location. Using the SSoT principle allows our code to be cleaner, more intuitive, and compliments two other coding principles: Don’t Repeat Yourself(DRY) and Separation of Concerns. By using these three in tandem, we’re well on our way to having great code.
Back to Single Source of Truth. My experience so far with SSoT has been with Object Oriented Ruby and ActiveRecord, so I’ll be speaking to that. SSoT is our best friend when it comes to the “Many to Many” relationship. To take a look at this, we’ll explore more of our coffee world. But, instead of focusing on origin, we’ll tweak the model slightly to talk about just a plain old cup of joe.
In this model, a drinker has many coffees and coffee has many drinkers. Well …wait- that’s a many to many! Sweet! That means we’ll need to have a Single Source of Truth to help join the two. Now, what’s a good place that could hold this data….? A coffee shop!
Above is the basic layout of our Many to Many relationship as well as our collection of instances. Our Coffee Class and Drinker Class are both created with a name. But, look at the information in our CoffeeShop class! Since we’re using Single Source of Truth, our SSoT(CoffeeShop Class) holds the reference to our coffees and drinkers. On CoffeeShop initialization, we create coffee, drinker, price and payment method, much like a transaction.
From here, we can use the @@all arrays and implement Ruby enumerable methods and iterate using block parameters to find come cool things about each individual class. But, since we have a SSoT, we can use the CoffeeShop.all array to find some cool thing in the Drinker Class. Woah! We can do things like — find how many total coffees have been had(assuming 1 per transaction) and who spent the most on one transaction.
We can even dig a little further to see all transactions associated with a particular drinker, how many coffees that drinker has had, and how much they’ve spent in total.
Cool! With all information being stored in our SSoT CoffeeShop Class, we are able to call on and manipulate that class in order to achieve a desired result. Pretty neat stuff, right? And this is just is a small glimpse into what’s possible.
With Single Source of Truth, we store and access our data in a single point of origin and are able to perform different methods on the class to filter out some pretty hip data. And, in the process, keep in line with Separation of Concerns of keeping it DRY. I’ll drink to that!
