On DevShed today there's a new tutorial showing you how to build a basic ORM layer on top of a MySQL database. It includes all the code you'll need (cut&paste-able, not as a download).

Obviously, with so many ORMs at one's disposal for free, it seems pretty pointless to develop a custom one; are we trying to reinvent the wheel? No, of course not. But if you need to create a simple application that performs a few CRUD operations on some related domain objects and don't want to climb the learning curve of a third-party library, then implementing a custom ORM might make sense. There's alos the educational aspect of the process (yes, learning one or two things never hurts).

They start you off with the creation of the "data persistence layer" (an interface first) to connect to the database, building a MySQL-specific one on top of it. Next up is the data mapper layer making things like "fetch by ID" and the insert/update/delete possible. Their simple example doesn't include anything about ORM relationships, though - just fetching simple rows.

In a recent post to the ServerGrove.com blog today there's a look at using the MongoDB with symfony to create a simple application with a NoSQL-based backend.

Part of our business is to develop internal applications and support customers, so we dedicate a good amount of time to research, test and learn new technologies. We have been following this whole movement and decided to give MongoDB a try. What has really taken our attention regarding MongoDB is its simplicity, yet how powerful it is. It lowers the barrier to develop DB-driven applications even more.

They start by explaining how to use MongoDB together with PHP and get both the server and client sides up and running. From there they introduce ODM, a object document mapper from Jon Wage (of the Doctrine project) that lets you easily interact with MongoDB instances. A code sample it provided to show how simple the tool is to use and how it can integrate with symfony as an entity.

Michelangelo van Dam has a recent post to his blog about a difficulty he was having with his Zend Framework application and setting up some data models.

I was struggling getting my data models (as described in the Zend Framework Quickstart) to work with relations. My first solution was to create a database view that merged that data using joins to collect this data in a format that I could use in my data models. This was going great until I looked at my database where it contained over 20 views (along with 20 data models, mappers and db table gateways) ! So I said to myself there had to be another way.

His other way came in the form of the Zend_Db_Table_Relationships component and, after a bit of work, it did just what he needed. He shares how you can set them up similarly by walking you through the creation of a sample application ("datamodels") and linking together a series of sample tables with a Db_Table class using relationships, a simple model to abstract data access and a model mapper class to redefine some of the based functions (like "findAll") to pull in data from other tables.

Guilherme Blanco passed along a note about the latest releases from the Doctrine project, Doctrine 1.0.8 and 1.1.0-RC2:

Today I am happy to tell you that we have two new versions of Doctrine available for you to use. The first is the monthly maintenance release for Doctrine 1.0 and the second is another release candidate for the newest major version of Doctrine, 1.1. As always you can grab them from the downloads page.

Updates in these two versions include a few backported fixes from 1.1, updates to the Doctrine_Query::count() method for optimization, and several fixes in the Release Candidate in preparation for the next release. You can see the full Changelogs here: 1.0.8 and 1.1.0-RC2.

In a new post on the SitePoint PHP blog today, Harry Fuecks has created a "wide finder" based on a project put together by Tim Bray.

Tim set a simple, but very much real-world challenge; write an app that determines the top 10 most popular blogs from his Apache access log. It should be fast and readable, with a subtext of illustrating how "language X" copes in terms of parallel processing and utilizing "wider" (many processor) systems.

Since PHP natively doesn't support multi-threading (well), Harry opted to go with an approach using curl_multi_exec instead. There's two pieces to the puzzle - the mapper to grab the information and extract the data and the reducer that makes the calls to grab the information from the log files.