the traditional wisdom is that the join is faster, because you have fewer round trips to the database. particularly if you are loading many parent items each with many child items. if you are loading just a single parent item, the second SELECT to get its child items is not a very large hit at all, and some would argue that its more efficient to issue two single-table SELECTs rather than a join on two tables. But its not more efficient to issue 20 single-table SELECTs versus a join on two tables.
a join increases the complexity on the database side, versus a single table select. so some architectures forego the usage of joins altogether (im talking large scale sites like del.icio.us and ebay)...but in those cases they have to have a plan in place to not issue tons of individual queries (i.e. lots of extra caching). this is why in SA we've tried to make it really easy to "switch" between the "lazy" and "eager" loading (i.e. using query.options()); its very dependent on what data you are selecting, and what data you need to see for the current operation. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
