Home/ Questions/Q 6727769
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T10:05:19+00:00

I’ve been reading something from Bill Karwin (creator of Zend_DB) about models not being

  • 0

I’ve been reading something from Bill Karwin (creator of Zend_DB) about models not being directly to do with database tables. (I think some devs have their models a direct extension of Zend_tables or so which makes it harder for adding memcached caching of objects, which makes sense.)

So what Bill Karwin was saying is that a Model has tables and isn't a table but I’m still thinking the way I have it is correct as its designed in an object oriented manner.

For instance (just an example):

A Monster has 1:M Mouth. a Mouth has 1:M Tooth.

So in my database I’d have 5 tables: 

Monster: id, name, type
MonsterMouth: id, monster_id, mouth_id
Mouth: id, size
MouthTeeth: id, mouth_id, tooth_id
Tooth: id, size, shape, sharpness

Then the 3 classes:

class Model_Monster { 
    private $id, $name, $type, $mouths = array();
    public function __construct ($id) {
        // Set properties from DB for supplied ID
        // Go through DB and add the mouths based on monster ID
    }

    public function countTeeth () {
        // Loop through each $mouths as $mouth and call $mouth->getTotalTeeth();
    }
} 
class Model_MonsterMouth { 
    private $id, $size, $teeth = array(); 
    public function __construct($id) {
        // Set properties from DB for supplied ID
        // Go through DB and add the types of teeth for this mouth ID
    }

    public function getTotalTeeth () {
        // return sizeof($teeth);
    }

}
class Model_Tooth {
    private $id, $size, $shape, $sharpness;
    public function __construct($id) {
        // Populate details based on ID passed
    }
}

Then I guess methods for counting teeth and stuff…

$monsterId = 1;
$monster = new Monster($monsterId);
// Count total teeth
$totalTeeth = $monster->countTeeth();

So a monster can have many different mouths and 1 mouth can have many different types of teeth.

After writing out this lengthy post I think I’ve got it right and that Bill Karwin is talking about those who have 5 Models rather than 3…

I have 5 Tables but only 3 Models as two tables are there to solve M:M table relationships.

2 of the 3 Models use composition to store many of the other type of object.

If a monster had 10 mouths of between 9-10k of about 10 different types of teeth… would this be a performance issue? I mean would PHP see it like: a,a,a,a,a,b,b or 5*a and 2*b. If having 1-100k of an object and iteratively adding them to a composite item is slow then I guess I should only have one occurance of it with a number property to say how many there are of that type.

If I’ve got it correct then maybe it might help some of the other guys who are having problems with this.

Thanks 😀 Dom

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Without wishing to put words in Bill the Lizard’s mouth, I think that rather than Many-To-Many-ness, he is more talking about the fact that you should keep separate your abstract concept of a business model from the underlying representation of it.

    It is important for example, not to rely on the fact that the fields in your business model have the same name as the fields in your database/document store/web service, because that makes it very brittle.

    Consider also, if your model wanted to a field like “FullName”, which was a simple concatenation of “FirstName” and “Surname”. You might not really want to store the “FullName” alongside “FirstName” and “Surname” in the database, because it’s duplicate data and more work to keep updated, but if your model is very tightly coupled to the underlying representation, you would either need to a) add “FullName” to your database or b) live without “FullName” in your model.

    By keeping a clean separation, you would be able to have “FullName” in your model and some piece of code that generated it, while just having “FirstName” and “Surname” in the database. Of course, it also makes it much easier to switch out the backend database technology, should you ever need to.

    The key insight from my point of view, is that a Model, more than just the fields it contains, is also the business rules, the validation and potentially the actions that you can perform on it. The table is just the handy place to store the fields necessary to underpin that behaviour.

    • 0