PHP ORM with full composite primary/foreign key support

Question

I'm looking for PHP5 ORM which fully supports composite (multi-column) relations based on composite primary keys and foreign keys.

I hoped that Doctrine 2 would solve this problem but it doesn't. It's a basic feature in relational data modelling but none of PHP ORM software I know supports it.

I've recently found that SQLAlchemy has full support but I need something for PHP, not Python.

Answer 1

When you're approaching the application from the database perspective something like Doctrine2 (PHP) or Hibernate (Java) from which it is "derived", is not appropriate. These are much more suited when you want to go the other way around (i.e. "I have an OO domain model and need to persist it in a relational db", not "I have a relational db and want a (generated?) OO interface for it, without making any compromises whatsoever on the database side"). If you use them despite this important differences in the approaches and you love your relational schema more than your object model you will just get frustrated.

It is really important to differentiate between different categories of ORM tools as they tend to focus on different development models.

Maybe try out Propel or RedBeanPHP, which seem suited for a database-driven development model with almost no mapping going on, just plain generated (and usually dumb) "data objects" and not much abstraction. Foreign key fields are just put into objects directly in these solutions, etc. so they might "support" all the composite stuff you want.

Solutions like Doctrine2 or Hibernate discourage use of composite keys and hence only support them up to a certain level (Hibernate goes pretty far but nevertheless they are not recommended to use).

Personally I'm not a fan of composite keys (with the exception of pure many-to-many link tables with no additional data) because I tend to approach things much more from the application/domain-model/object side and there composite keys that are mapped to objects are often a pain to work with, even if the underlying mapping technology supports them. Surrogate keys (or at least single-field natural keys) make things much simpler. I'm not a relational-database-normalization-fetishist and the "better performance" is highly questionable from my point of view. Saving an occasional join won't save you if you have real performance problems in a system.

Answer 2

Doctrine 2.1 solves this problem completely.