About a year and a half ago I began work on a multi-user, multi-calendar event management system for my job. It was a side project as something that “might be useful in the future” because the main event management system that we were using was old, buggy, and we had no control over it to expand it. Version one came out and worked fine, but since it was a fairly complex system, especially for one coder to build, I wasn’t happy with the way a lot of the process steps flowed. I also wanted to add more features and move it to the Smarty Template Engine, so I started a complete re-write from scratch.

While working with one of our UI designers and redesigning the database, I found that one of the ugliest parts of my code arose when making any changes to the database. I had abstracted all of the queries themselves into a single Database object that contained all of the methods that I needed to fill in different forms, obtain different lists, and so forth. While this was nice, if I ever needed to rewrite a query for a single operation, I found that a lot of the operations were redundant. It was difficult to update anything when even small changes happened to the Database schema.

At this point, our sysadmin was finally setting up a PHP5 server, so I was able to start using proper objects and wanted to move toward a more object-oriented approach to PHP coding. I have worked on other projects outside of my job which gave me a very good introduction to PHP5 objects. Additionally with a professional coder for a tutor with his years of experience, I felt comfortable that I could do it. This is how PHP-OOdb was born.

My basic requirements for the system were:

1. It has to play nice with Smarty. Even if I include the files globally to set up the database connections, it had better not make a connection until I actually USE the database. That way, if I decide to pull from a cache instead, I don’t waste the overhead of opening and closing a connection.
2. It has to be object oriented and in a good way. I wanted to use design patterns to make it more easily understandable.
3. It needs to be completely generic. I want to be able to use this on all of my other projects to make my code cleaner and my productivity higher. If I can actually use it, then maybe other people will find it useful too.
4. It has to be all my own code.

I looked into the ActiveRecord design pattern and some implementations with the Object-Relational Model and the most aggravating thing for any of them was handling inter-object relationships. I wrote PHP-OOdb in the way that seems the most inituitive to me.

I have also written up some documentation to go with it. The home page for the system is http://fugitivethought.com/projects/php-oodb. Documentation and examples are posted there as well.

I hope somebody finds it useful. Any bugs or comments or insults, please post here for now. If there is honest interest in it, I can set up forums / wiki / bugzilla and properly maintain the project. If you know of an alternative that is good and you have recommendations, I am very much open to using them instead.