
Illustrating some of the most common misconceptions and pitfalls software developers face using relational databases, this book helps readers use a database to produce the most efficient results, and turn sluggish, inflexible code into high-quality, reliable solutions.
That said, sometimes when I realize there's no way for me to come up even with a rough schema (say, some settings object that is returned to the frontend), I use JSONB columns in Postgres. As a rule of thumb, however, if something can be normalized, it should be, since, after all, that's still a relational database despite all the JSON(B) conveniences and optimizations in Postgres.
I wouldn't worry about this too much. As long as what you're doing seems to vaguely match whatever information about best practices you can find online, you're probably good. As long as you're not inventing your own security tech, using floating point values for financial data or reusing feature flags in a high frequency trading scenario, any bad decisions made along the way probably won't be catastrophic and are more likely to be learning experiences.
More eyes on code is a good thing, but can go too far where a person is cargo culting their beliefs and subjective experience as objective things, leading you to learn the wrong stuff, or at least to a degree where you have an irrational attachment to some practices (e.g. some people always lean towards EAV in DB design, even though that practice has a time and place, same for microservices vs monoliths vs modular monoliths etc.).
> ...and might be missing out on a lot of learning.
This is probably what you should focus on. See if you can attend industry events, watch some talks done by people who've been in the industry for a long time, there's actually lots of nice stuff on YouTube that's not just advertisement for the latest technology or practice. Here's some people whose content I enjoy:
Dylan Beattie
Venkat Subramaniam
Kevlin Henney
Maybe look at some of the better received books. Here's a starting point: A Philosophy of Software Design
Algorithms
Building Secure & Reliable Systems
Clean Architecture A Craftsman Guide to Software Structure and Design
Clean Code
Code Complete
Design Patterns Elements of Reusable Object-Oriented Software
Next-Level Database Techniques For Developers
Patterns of Enterprise Application Architecture
Peopleware
SQL Antipatterns
The Clean Coder
The Mythical Man Month
The Pragmatic Programmer
Working Effectively With Legacy Code
Again, take none of that as gospel, but maybe give them a passing glance.Also, props to whoever mentioned learning by doing in a low stakes environment (side projects) and online communities!
In the end, he compares five hierarchical data designs. Unsurprisingly, all have pros and cons and it is a (somehow advanced) matter of picking the right tool for the job. Closure tables may in fact be the lesser know variant, adjacency lists and recursive queries one of the better knows. But there are also path enumerations and nested sets.
What I have discovered recently is that it's really useful (or at least I am inclined to do that) to keep track of you daily findings or useful ideas as a developer.
An example is a pretty simple technical concept like dealing with polymorphic associaions in database modeling. There is nothing rocket sciency here, but having read a chapter in Bill Karwin's SQL Antipatterns book, I feel like I have learned a lot.
That said, it often happens that you might not encounter certain techniques or approaches for a long time and your knowledge fades.
This is why I briefly described the problem solved on my Notion journaling page, noted the book chapter and tried to summarize the approaches I considered and the one I ended up with (and why). At least, now I feel some kind of mental relief :)
What approaches do you use to make sure that your new pieces of knowledge do not evaporate too fast?