Spanspek

The so-called Active Record pattern has gained a lot of currency thanks to Ruby on Rails. According to Martin Fowler:

An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database.

The purpose of this post is not to discuss the merits or otherwise of this approach. One supposes that Ruby on Rails does something like what Fowler describes. It should be noted that some would suggest that this violates separation of concerns: a domain object—an object representing either a single database record or a complex of data which together models something like a real-world entity—should not be concerned with retrieving its data from, or writing its data to, a database.

I sort of agree with this, not least because every domain object has to carry around the baggage concerned with storage. One could simply have another object which performs the database transactions and reads data from the domain object for insertion to or updating the database or retrieves data from the database and sets the domain object's properties with its values. This is the approach that eZ Components takes.

Anyway, in thinking about this, I thought that I might learn something about database relations by "rolling my own". For my first attempt, I wrote a fairly simple MySQL database connection object and a statement object based on PDO. (I like PDO a lot.) Then I discovered a side project of Troels Knak-Nielsen, author of Konstrukt, called pdoext. It's a library for composing SQL. It still requires that you have a knowledge of SQL, but it does do some of the grunt work, and is especially useful when certain parts of an SQL query are composed at runtime.

I thought I'd implement composition of common relations such as:

• OneToOne
• ManyToOne
• OneToMany
• ManyToMany (what, in Rails parlance, is called "has and belongs to many")

However, there are some things I want my library to do which I've not seen elsewhere.

1. It should spit out domain objects. This cuts out the "middle man" approach of using a gateway of some sort to create and then populate each domain object. PDO facilitates this behaviour with its PDO::FETCH_CLASS constant or PdoStatement::fetchObject() function. (Actually, recently I have seen this done. I just can't remember where!)
2. It should allow selection of database fields in the query. Many Active Record implementations do something like "SELECT * FROM tablename". Many programmers and database administrators say that one should fetch only what one needs to reduce the amount of traffic between the application and the database server.
3. It should facilitate some customization of queries (more on this in a later post). I'm sure there are some libraries that do this, so please don't flame me for this point.

Now, I've been working on this for some time, so rather that writing a series of posts about how I'm going (with all the trails and tribulations and changes of mind and so on), I'll write a series of posts that plot a brief history of my decisions. Code examples will be included, of course.