A perceived complexity

This question I've heard during one of my interviews quite a while ago: "How you handle high-demand database requests when you need to perform five or six joins with data tables?" ("data" is emphasized because user data tables and not lookup tables were in scope - I clarified this specifically). The question is not important (I guess "that's stupid" was good enough answer). The join details are not important either. What was important - the question assumed a necessity of an unneeded complexity.

Honestly, it was the first time I gave it a thought. Look at formalization of your applications - how many relations require more sophisticated approach, than "one-to-one" or "one-to-many"? To your surprise you can find that it happens rarely, if ever. In most of the cases, when I though that complexity existed, I was proven wrong. And you know why? Because the object model of any intricacy comes down to the user-facing interface and humans are notoriously unable to tackle the overcomplications you think to unleash on them. That particular interview question was about building a robust forum portal, and functionality looked overwhelming - all those sub-portals and forums with discussions, posts, comments, cross-links and other stuff. But any meaningful user function drilled down to the same parent-children routine: forum with discussions, discussion with posts, post with comments and so on. User doesn't care about surrounding complexity while dealing with convenient and comprehensive "one-to-many" entity.

Higher level of complexity can even serve as an alarm bell - an indication, that business rules are handled in the database. In this case big joins is not your biggest problem.