10-15 joins in one request - an antipattern?

Question

Database design

Is 10-15+ joins within a single query a sign of bad database design or a bad choice in favor of relational databases in general? Or is this the norm for relational databases?

The speed of requests, although not the fastest, is still satisfactory, but the kilometric request is doubtful. I didn’t work closely with other databases, except for relational ones, but something tells me that there is a solution that 1) will shorten kilometric unreadable queries; 2) optimizes execution time

Answer 1

will shorten kilometer-long unreadable queries

Use macros, ugh, views.

optimizes execution time

Use stored, ugh, indexed views. And stored, precisely, calculated fields.
This is for simultaneous 1+2. For the rest - another question with the text of the request (for the picture - etsih with nails) and the tag Оптимизация SQL-запросов.
Oh, and if you have it for reports or analytics, then you should look at OLAP .

Answer 2

why do you need so much data?
If for analytics, then the norms. And if for simple lists something went wrong

Answer 3

You can't analyze code without asking yourself the question "why"?
If the data is really complexly connected and there is no way without these joins, then the point is not in the request, but in the task or architecture.
And if the joins are mixed, just to make one instead of five requests, and they are easily separated - it makes sense to compare both options, perhaps this is an attempt at "human" optimization, which actually only prevents the database from caching frequently requested data.