Fix performance problems

[hwbllmnn]

When requesting applications in certain projects with their own model extensions, performance will sometimes drop dramatically. The problematic SQL statements had the following characteristics:

• they used a ridiculous amount of left outer joins (more than 80)
• they were joining over a couple of (select ... union ... union) subselects

In order to reduce the amount of joins this PR removes some of the fetch mode annotations (or changes them to subselect) (in order to avoid too many joins at once) and changes the inheritance strategy for all related classes to joined instead of table_per_class (in order to avoid the unions).

Please note that this will result in changed table structures, so we should only merge this after a new release.

@terrestris/devs please review

[marcjansen]

We had this this forth and back... really annoying. I tend to think that inheritance isn't the right approach here. If possiible I'd delay merging this until we have feednack from @buehner

[buehner]

As the changes will result in changed table structures, this is a hard topic regarding backwards-compatability, right? As long as we start new projects or we can boot in CREATE-mode, this would be fine.

I love performance enhancements, but i dont like breaking the backwards-compatibilty. I dont have a strong opinion right now.

This change should result in a 1.x.x release, right? Maybe we can still maintain a 0.x.x branch for backwards compatibility. What do you think?

[hwbllmnn]

You're right about that. I think doing a 1.x and maintaining a 0.1.x branch for backwards compatibility sounds like the right thing to do.

Just note that this actually fixes scalability issues and doesn't just improve performance.

[marcjansen]

Then please do the releases and proceed as discussed. Thanks everyone