<p>Can someone please derive a concrete example from the following:</p>

<p><a href="http://www.urdalen.com/blog/?p=210" rel="nofollow noreferrer">http://www.urdalen.com/blog/?p=210</a></p>

<p>..that shows how to deal with <code>one-to-many</code> and <code>many-to-many</code> relationships?</p>

<p>I've emailed the author some time ago but received no reply.  I like his idea, but can't figure out how to implement it beyond simple single table relations.</p>

<p>Note: I don't want to use a full-blown ORM.  I like doing my SQL by hand.  I would like to improve the design of my app code though.  Right now each domain object has its own class full of queries wrapped in static methods.  They just return scalar, 1d-array (record) or 2d-array (recordset) depending on the query.</p>

The problem of ORM's (The impedance mismatch, as it's called) is precisely with relations. In an object graph (In-memory objects), relationships are pointers to other objects. In a relational database, relationships are reversed; This makes it impossible to do a simple mapping between the two models, and that is why ORM's are so complex.
If you want to stay close to the database (avoiding an ORM), then you shouldn't try to abstract relationships away. The way I write datamappers is something like the following:
```
```
$car42 = $car_gateway->fetch(42);
$wheels = $wheel_gateway->selectByCar($car42);
```
```
In contrast to the ORM way:
```
```
$car42 = $car_gateway->fetch(42);
$wheels = $car42->selectWheels();
```
```
This does mean that the gateways end up in your client-code, but it also keeps things very transparent and close to the database.