Blazing performance in this case is not the primary objective, rather it is maintainability and extensibility. So given that, I'm inclined to take your advice to normalize and use joins.

As far as the object model goes, you're preaching to choir my friend :^) Even if I were to combine the classes into a single Asset, the differences would be minor enough to incur almost no performance degradation over the model with inheritance. However, as a matter of good OO design the latter clearly wins out.

Update: In my object model I've decided to solve this dilemma by separating out the database interactivity according to which attributes belong to each class. In other words, Asset is responsible for saving only its attributes in its own table, and DocumentAsset's database methods rely on SUPER to inherit the necessary behavior. Thus, DocumentAsset::save calls $this->SUPER::save() , and then proceeds to save only its distinct attributes in its own table, namely, docid and label. So far so good :^)

thanks pg.