Why we don’t need JOINs

OQL uses subqueries instead of joins for filtering based on values in related data source objects. We would use a subquery relating Employee to Address in order to limit the employees to residents of California. Joins and subqueries are functionally equivalent and perform equally well in all industry-leading databases. They also translate more directly to capabilities of non-relational data sources.

We don’t want to use joins to merge fields from different tables. We don’t want the PersistenceManager to return an ad hoc mix of data from the Employee and Address tables[1].  When we need the employee’s home state we will use entity navigation[2] and write anEmployee.HomeAddress.State instead.