Yesterday, I asked Mark Mandel for some advice on tuning my object model for performance. Mark, being an ever-so-helpful (P)OSS author, gave me a few suggestions. Turns out that someone asked basically the same question on the transfer list today. Jaime Metcher made a couple of excellent points on choosing between queries and object composition. Paraphrasing, Jaime, when working with large data sets (the type of thing you might be tempted to use arrays of objects for), you will get better performance using a query. If you want to display a single instance of some object and the view is truly a composite, then your model should reflect that composition. Understanding this helps with choosing between onetomany or manytoone relationships for your object compositions.I have a pretty good use case going on right now for just this type of thing, an accounting system. Knowing that I will want to have an Invoice view that has InvoiceItems and Payments, I chose to make those relationships onetomany. To display an Invoice, I pull a single composite object and loop over the InvoiceItems and Payments as arrays. I do the same with Orders (which can recur) and OrderItems. All of my remaining relationships are manytoone, so that when I load an object high up the food chain, I don't load cascading arrays of child objects. Here's a generic diagram of (some of) the objects in my model. This was a big revelation for me in terms of modeling. I've always known at a low level that the view should drive the model, but this exercise really drove it home. Of the many learning points I've had over the past couple of months (ant here have been many), this one feels most significant.