Oh my.. we're at PHP-Query already.
Okay, let's do this right!
The PHP-Query project is designed to be an ORM. Well, my version of an ORM. I'm no CS graduate, so I kind of just winged it. Tangents aside, it's an ORM developed for PHP that generates SQL queries through a clean, semantic API.
It's not designed to be fast, but it is designed to be very readable (from a programmatic perspective). It's got everything I could need in an SQL query made available, and especially useful when working with complicated data that needs to be injected into queries.
That's a perfectly great question. There are ORMs out there, many of which are implementations of Ruby's ActiveRecord pattern. This is for good reason: ActiveRecord is wicked.
Yes, it has it's limitations, and challenges, but is a beautiful execution of a useful idea. Wait, back to the question.
I developed it because I wanted to have complete control over the execution of an ORM that was completely independent of a framework. CakePHP has one. CodeIgniter has some. But they have expectations of how you wrote all your other code. They need to play nicely together.
I wanted one that could be stand alone. One-page site, but with super-complicated queries? Got that covered!
This library is dry. It only contains one class. But oh, what a class it is :)
Query objects have a delirious number of methods available to them. Some
aliases of one another, but all with the intention of being semantic. Logical
naming conventions that lead you to understand the query you're programmatically
As mentioned above, I wanted it to be useful outside of an existing codebase or framework. I personally don't like using frameworks (obviously other than TurtlePHP), and wanted an 'ORM' that could be used on a tiny code base, gigantic codebase, or anywhere in between.
PHP-MetaParser, you're next!