If you have a query that interrogates BOG and the Member BOs of those BOGs have shortcuts and relationships and then you run the SQL log you'll see the query individually load all of those relationships.
When you do your load testing, you'll find that all of those BOs then create a MASSIVE overhead on the system and your system will slow to an absolute crawl.
Here's a video to demonstrate. There are two queries, one on the left is EXEC_SQL which creates a view the one on the right is a standard FIND ALL BOG query.
The video is 9 seconds long, let it run, it looks like it has stopped but it hasn't. The second query takes 6 seconds longer to complete than the EXEC_SQL one. All of the rules have been switched off for the BOG elements, the time lag is due to the way every record is being loaded into context.
This is obviously going to elicit a hard no from a client.
There needs to be a way to bring all of the records into context, without bringing anything that is not in required for the query. This will obviously have an impact on any processes that run on the records to bring that record back into context for processing, but that overhead is more easily managed than the initial experience of first loading the grid.
My initial plan was to use EXEC_SQL to bring the objects into a fake BO (i.e. one that exists only to pull this query) and then use the BO ID to find the real object for displaying the record, however it seems that objects that are retrieved in this manner are not real objects.
Details on the query.
BOG of 6 member BOs
3,500 instances
Several layers to child objects to each BO
