Table Module vs. Domain Model

The best reference is "Patterns of Enterprise Application Architecture" by Martin Fowler:

Here's an excerpt from the section on Table Module:

A Table Module organizes domain logic with one class per table in the database, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model is that, if you have many orders, a Domain Model will have one order object per order while a Table Module will have one object to handle all orders.

Table Module would be particularly useful in the flexible database architecture you have described for your user profile data, basically the Entity-Attribute-Value design.

Typically, if you use Domain Model, each row in the underlying table becomes one object instance. Since you are storing user profile information in multiple rows, then you end up having to create many Domain Model objects, whereas what you really want is one object that encapsulates all the user properties.

Instead, the Table Module makes it easier for you to code logic that applies to multiple rows in the underlying database table. If you create a profile for a given user, you'd specify all those properties, and the Table Module class would have the code to translate that into a series of INSERT statements, one row per property.

$table->setUserProfile( $userid, array('firstname'=>'Kevin', 'lastname'=>'Loney') );

Likewise, querying a given user's profile would use the Table Module to map the multiple rows of the query result set to object members.

$hashArray = $table->getUserProfile( $userid );