Main points are :
- Each transition serializes the execution and results into a SET of select statements :
- Each transition to a child level in a named query (regardless of the actual number of levels / entities you transition through) results in a sub-query that fetches records referring to a list of F_IDs from the parent level.
- Each transition to a parent level results in a select statement that returns the record whose ID matches the child record's F_ID.
- Named queries were implemented that way to make paging easier and to avoid parsing huge tables of data returned by a single query, in the same way Excel processes a data range to generate a cross table with a tree-like structure. This would be resource-intensive and taxing on both RAM and CPU.
- Good practices are
- any attribute born by a parent entity should be retrieved by the "root" sql statement using a fully qualified name like ParentEntity.AttributeName instead of a parent node
- transitions towards child entities that have too many levels would end up executing a lot of select statements. So any transition that is not necessary should be avoided: middle-man in a many-to many relationship.