Complex-ish SQL queries in Typescript using TypeORM

I have, as a teenager, fiddled around with phpMyAdmin when fooling around with WordPress and OGSpy, back when OGSTeam still relied on SVN for versioning, and I didn't know crap about development, let alone architecture.

Complex-ish SQL queries in Typescript using TypeORM
Photo by Rick Mason / Unsplash

I have, as a teenager, fiddled around with phpMyAdmin when fooling around with WordPress and OGSpy, back when OGSTeam still relied on SVN for versioning, and I didn't know crap about development, let alone architecture.

Simply put, while I did have some general culture on the topic of relational databases, and had written a few SELECT while trying to get through some prospective client's or employer's online coding challenges, it never went further than that. Until last year when I had to work with an SQL database for the first time in my life as a software engineer.

Which is also when I faced a small albeit fun challenge.

Context

Let's suppose we work for a huge software services consulting and contracting firm. The kind most of us would rather not work at.

The kind of firm that gets sued for $32 million for failing to deliver a non-responsive design e-commerce website.

The kind of firm responsible for this sort of software (the post isn't available anymore, hence the Wayback Machine link; given how badly it breaks the design, I suggest using your browser's reader mode for readability).

Or the kind of firm that somehow manages to spend over a decade and €80 million (I couldn't find a page in English, but it should be easy to translate using DeepL) building a steaming pile of crap that somehow manages to cost an additional €76 million in damage control.

Lost Hallway
How I imagine the second post's firm's offices - Photo by Matthew Feeney / Unsplash
lost in space
Insight into the software's architecture - Photo by Martijn Baudoin / Unsplash
Splatter paint on white table
Louvois' latest UI mockup - Photo by Ricardo Viana / Unsplash

The Actual Context

No. Let's not do that. Instead, let's suppose we work for a much better, yet still huge, software services consulting and contracting firm, simultaneously working on a few thousand projects.

The (fictional) project we are working on is an internal one. A SaaS that will enable our coworkers to better understand the different projects the company is involved in, how they are doing, etc... to avoid ending up like the three I mentioned earlier.

And this project uses an SQL database.