Stuart Clarke wrote: > And the final question: is SQLAlchemy any better in this regard? I am no SO user, but I think part of it depends on the kind of complexity the schema is covering. Having a rule of a single-column surrogate primary key can force the developer to use more joins or more queries than he would like, for instance.
I've never needed to benchmark queries, but I have the feeling that most times the performance problems comes from the schema design, I am not talking about huge sets of data but the kind of heavily related tables that are typical in an enterprise application. Sqlalchemy poses no restrictions on the relations (I _do_ love autoload), or the queries you can map an object to, and that sometimes helps performance. This is not an attempt to start a religion war on surrogate keys ;-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
