There are no scalability problems with objects per se. Not that I've run into, at least. I have yet to see anyone demonstrate any scalability problem with objects themselves.
Permissions have problems and I've been doing a fair amount of thinking about how to fix them, thinking I'm hoping to work on for 4.7. Objects per se are not the problem. acs-rels per se are not the problem. The problem is a combination of several things in the data model that lead to execution plans for permissions queries that are heavy on nested loops that break the kind of O(log2(N)) type scaling one hopes to see with btree indexed tables. And the UNION views meant to be used within general queries don't scale, we all know that.
This has nothing to do with objects, though.
acs-rels themselves are probably too heavyweight and should be trimmed into a lightweight facility that doesn't make a new object for every row in the mapping table. IMO making each row in the map an object just wastes space and time without offering useful benefits. But you don't have to join with the object table in order to make use of the mapping table so from a pure speed-of-query point of view the fact that there are garbage rows in the object table doesn't matter.
Even in this case, though, Branimir's comment about acs-rels and scalability is really a comment about problems with scalability of the permissions facility. And this problem is largely related to how groups, relational segments and permissions interact. Build groups out of a lightweight mapping table rather than acs-rels and ... permissions still don't scale, not the way they're implemented today. I know because I've studied the code and execution plans for queries that involve the permissions system in great detail while helping Sloan/MIT make dotLRN scale.
So folks should quit worrying about objects and worry about the permissions system, instead. I know that improving the performance of the permissions system is going to be #1 on my personal list for 4.7.
As I've mentioned in another thread, judicious caching can help a lot. I've been working on improving my caching db api, incorporating improvements from the Berklee School of Music (who use it heavily in their extensions to dotLRN) and some newer ideas of my own. It is silly to be continously hitting the database for stuff that we know rarely changes.
