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.

[More]

While cleaning out the office recently, I ran across a couple of textbooks I kept from my business school courses. I didn't care much for business school, but I did learn some valuable concepts. A few of which came from a course on Organizational Behaviour (OB). OB is a "management science" which can be briefly described as the study of groups in organizations. A goal of OB is to determine the best strategy to use within an organization to maximize employee performance (productivity) and, as a result, profitability. If you think of an organization with managers and employees, where each employee performs specific duties, you might find it strange to have a manager for every employee. You rarely see this in the real world, because it is grossly inefficient.

[More]

I've been using UML more often to visualize object relationships, so after reading Brian Rinaldi's recent posts on ColdSpring, Objects and Composition, I researched object composition and learned the subtle difference between Composition and Aggregation.

[More]

To go along with my previous woolgathering on the correlation between a database schema and a class package, here is another observation regarding class inheritance and sub/supertype tables.

In object modeling, we describe the relationship between a subclass and superclass as "is a". The same goes for tables in a data model, where the subtype "is a" supertype. The obvious benefit of using inheritance in object modeling is code reuse. When we add, remove or alter a method of the superclass, the change is automatically inherited by the subclass. In a data model the benefit of using subtypes is arguable. The benefit are that your model better represents the domain, reduces data duplication and (depending on the extent of your normalization) eliminates NULL values. The trade-off is that you are thereafter required to use joins when reading records and transactions when creating, updating or deleting records.

[More]