In a traditional RDBMS, why are Many-to-Many Joins so much more resource consuming than Many-to-One joins?
An SQL FOREIGN KEY
(FK) constraint holds when subrow values for a list of columns also appear elsewhere as a UNIQUE NOT NULL
(superkey). So for every row in the referencing table there can be only one matching row in the referenced table. So the result of a JOIN
ON
equality of a FK & its superkey can output at most one row per row in the FK table. Whereas in general since a JOIN
returns every possible combination of rows that can be made from input rows that satisfies an ON
condition, in general there can be many more rows output.
After all, aren't Many-to-Many relationships just like two Many-to-One relationships?
It's not clear what you mean by "just like" or how you think it suggests or justifies anything. And a join is not a relationship. (A table represents a relationship.)
- How does one predict memory and CPU requirements against expected performance? (Is any benchmark available?)
Many SQL DBMSs have a query planner/optimizer EXPLAIN
command & others for inquiring about what a query will or did do or cost.
Read about (logical & physical) relational query optimization/implementation, in general & in any particular DBMS. Wikipedia happens to have a decent article. Many textbooks are online.
- Past which thresholds is it worth using other solutions instead? (MPP or NoSQL)
Re NoSQL search my answers, of which the most recent are:
How to convert an existing relational database to a key-value store?
How does noSQL perform horizontal scaling and how it is more efficient than RDBMS scaling
Reasonable Export of Relational to Non-Relational Data
RDBMSs offer generic straightforward querying with certain computational complexitiy & optimization opportunities. Relatively speaking, other systems specialize, with certain aspects improved at the expense of others.