My top 4 ERD design tips (from my perspective as a SWE bootcamper ):
I recently challenged myself to create an eCommerce web application where I first had to map-out an Entity Relationship Diagram (ERD for short). For the uninitiated, ERDs are visual representations of a database schema; in even simpler terms, they depict how information stored in a table relates-to/interacts with information stored in other tables inside your database.
It’s important to put careful thought into ERD design because ERDs chart how data is stored and retrieved in your application, and you’ll be referring back to it regularly during the coding process. When the ERD design process is taken too lightly, you could find yourself upheaving chunks of code later on, and hence many of us are keen to get it right the first time.
On the other end of the spectrum, you could find yourself going down a rabbit hole in pursuit of the “perfect” ERD. Spoiler: the latter is the reason I’m writing this article in hopes that it helps a fellow learner navigate the experience better. Here goes:
The law of diminishing returns applies
When I began designing my ERD, I told myself that I would spend as much time as needed to get this ERD right. Heck, it had to be perfect.
BIG MISTAKE. This is my first point of reflection because I think so many SWE freshies (myself included) are going to think this way. I now know, however, that this expectation is unrealistic for those of us just starting out (i.e. You’ve designed less than 10 ERDs ).
Fact: Due to inexperience, spending an extra 2/3 days contemplating ERD design will not give you much more foresight to anticipate most (let alone all) of the future problems you will run into when the coding process starts. Whether you spend a day or 3 on ERD design, when you eventually begin coding you will likely run into unexpected issues/ challenges that make you question your e̶x̶i̶s̶t̶e̶n̶c̶e̶ ERD. So in summary, don’t be afraid to spend time drawing your ERD, but also realise that there comes a point where that extra day (or 2) invested in ERD design will yield marginal benefits in progressing your project.
But this begs the question: when should I move on from ERD designing and actually start coding? Cue point 2.
Start when you have an operational ERD
The keyword here is operational , and for intents of this article is used as a juxtaposition against complete or perfect ERDs. When something is described as operational, it is also recognised as a work-in-progress (WIP), and should be expected to require further refinement in future.
An ERD is operational once it has all the tables necessary to get your application up-and-running to complete its most basic/crucial function(s). At this point, it’s time to start coding! For me, the hardest part in achieving an operational design was… (over-)ambition. It seems ludicrous on hindsight, but as I was designing my basic ERD I was already thinking about what data to collect and how it should be stored to enable analytics on products and sales figures; and I was getting stuck on problems associated with these, which held back my progress in developing the application.
Instead, I should have focused on creating an operational ERD that was good enough for me to start coding the basic functionality of my application, enable me to fail fast, and still have sufficient time within the project timeline to remedy the problem or else pivot entirely, if necessary.
Relax, you’re not screwed.
Let’s just get this out of the way, you ARE going to run into unexpected problems with your design. Breath in, out, repeat. This is why it’s so important to recognise that at this point our ERDs are still WIPs, and will need refinement along the way.
In my case, I was a week into a 2-week project when I ran into my first major setback and started doubting the viability of my ERD ( mind you, this was after having already spent ~3 days creating what I thought was the perfect ERD). By the time this happens to you, hopefully you would’ve taken my advice and not spent ~3 days trying to create the perfect ERD, and have a couple more days to remedy the situation than I did.
The secret sauce: finally creating the “perfect” ERD
Throughout this article, I’ve discussed the “perfect” ERD as somewhat of an ideal that lies beyond grasp. However, it’s important to qualify that the perfect ERD does exist, and is completely within grasp — but it probably isn’t what you want it to be. Before I started this project, the perfectly designed ERD I had in mind would enable information storage and retrieval in the most eloquent way; have 0 inefficiencies — information that can be stored in one table would not be in two; Scaling up to enable analytics? Easy-peasy…Until it’s not.
Truth time: Most of us aren’t trying to create the next Amazon or Facebook […yet ;) ]. Instead, we’re perhaps working on a limited-scale product, like a school assignment. In these scenarios, grandiose ERD designs will only hamper progress. Sure, it would be really impressive if we were able to pull-off an eCommerce application based on an Amazon-like ERD in just 2 weeks, but you also risk hitting the project deadline and only having a half-baked application to show.
Hence, my final tip is this: ERDs shouldn’t have to be as complicated as your ex. The perfect ERD for your project is the one that best enables you to achieve your primary objective in the limited time you have. Sure, there may be less-than-ideal compromises involved, but at least it ensures you create a minimum viable product that is presentable. To help yourself achieve this, clearly delineate your primary objectives and stretch goals at the outset, and be disciplined not to conflate the two!
That’s all my tips for now, happy designing!
