I'll leave the back-end part of this response to those far more experienced. My specialty is with front end design combined with Nintex Workflow/Forms. My answer does not get directly to your question regarding preference to query or make a relationship. However, the list architecture of a sharepoint site, and thereby the solution you build, does have relevance. And since you spoke of having "no SharePoint experience" I thought I'd offer a crumb for consideration.
From a front-end point of view it's worth understanding the Lookup column in lists:
- They support the ability to restrict behavior (prevent deletion of parent-child relationships)
- By default you can have upto 12 lookups on a list to other lists (this can be increased)
- List lookup columns are restricted to the same site.
- From a UX perspective they're brilliant. They result in a hyperlink that opens in a dialog when pressed, and provide brilliant reference to relevant information.
- From a manipulation perspective they store an ID and the name of the referenced item. This means they can be manipulated to great effect in workflow. I once built a no-code/workflow only master scheduler list for a construction company's approach to four different types of project build and used workflow to manage the automated build a project plan that tracked multi-checkbox lookup fields for Predecessors. Changing the dates on a task would cascade date changes all the way down the project plan. The client LOVED it.
As a side note, my experience is fairly deep with the front-end of SharePoint, and for nearly 10 years I've been building low-code/no-code solutions in SharePoint. I've even gotten an IT Excellence award in 2015 from the University of Alberta for a system used to assess the training of medical doctors. I don't claim to be the ultimate authority, but I do offer this suggestion. If you want to learn about developing SharePoint invest some time in learning how the front-end of SharePoint works. There are some limitations, but there are some outstanding possibilities in learning how to manipulate the front-end of SharePoint. This includes clients phoning me at 9am on launch day for a new version with a missed requirement in testing (their miss) to have that change implemented for a successful roll out by lunch time.
Programming in SharePoint will get what your client/business needs (most of the time). How long it takes to build and test is one thing. What the impact of changing the SharePoint stack is on upgrades to a future versions is another thing (I've heard of heinous horror stories of code slingers dropping such badly written code into a farm that it took nearly three years and a SharePoint Master to try and fix it - they still lost over 50% of their programmed functionality). But regardless of the myriad of opportunity you will only be well-served by learning how SharePoint works from the user's perspective when considering how to develop on the platform.
Best of luck!