Data retrieved as array of arrays vs array of objects

I was working on a project made in a MVC framework and I was wondering which approach would be better for storing the data retrieved from the database.

Would it be better to retrieve the data as an array of arrays or using an array of objects of a specific type? And why?

For example, when applying the second method, if I retrieve products from the database, the objects in the array would be an instance of the class "Product".

Hi,

most modern frameworks map the tables to classes and the rows to the corresponding objects (called ORM). The big advantage of this is that you can actually encapsulate the database logic in those objects. So instead of making queries, you call certain methods like $product_xy->save().

Using multi-dimensional arrays would be a more classical, procedural approach. While this is very lightweight and simple, there's no guarantee for data integrity (the arrays can contain anything), and you need "raw" SQL queries in your application.

So it's basically up to you. Are you willing to put extra effort in a clean solution? Or are you OK with query stuff flying around in your scripts?

The framework I'm using is Zend so the queries are not an issue, because I only need to pass an array of data to the appropriate method.

The method, with the object that I mentioned above does not map the rows to the corresponding objects, it only holds the data I pass to it (the Product class extends the ArrayObject class and extends it's functionality), therefore I don't have many advantages over an array.

Ok, so let's say I decide to use an ORM style approach; won't it create overhead when trying to link 2 tables? For example let's say I want to associate a product with a category (let's say it's a new product). Basically I would need 2 objects: a product object and an object that identifies a row in the associations table.

Yes, an ORM would add overhead, but the potential for really clean bug free code will probably be worth it. There may be additional benefits like speed in development as the ORM may handle relationships for you (at least after you've configured it to). A proper ORM wil be able to associate the category into the Product object. So when you instantiate your product object, it would know to map the category automatically behind the scenes for you. Check out Doctrine 2. I believe that's used quite a lot with Zend.

Thank you for the help.

I will check out Doctrine 2 (heard of it but never had a chance to use it) and see if the overhead is worth it for my project.

Another big PHP orm is Propel I believe, though never used it.

Both propel and doctrine have a lot of overhead associated with them. Propel, in particular, uses 7 PHP class files for every database table.

The efficiencies of ORM layers are code efficiencies, not execution efficiencies. It's easier and cheaper to buy a faster processor than it is to develop for an extra month.

Hell, it's easier and cheaper to buy a faster processor than it is to developer for an extra half day.

I prefer Doctrine over Propel. Unfortunately the Doctrine documentation for v2 is not great. There is also one type of join relationship that Doctrine can't handle, but I don't recall off the top of my head which one it is.

Doctrine doesn't support composite foreign or primary keys (or didn't when we attempted to use it for our major project) so I recommend against it based entirely on that. The join conditions don't work when there's two pieces of data being joined (like, for instance, your data is in proper normal form without arbitrary auto-increment IDs).

Version 2 does support composite primary keys; I'm not sure if it supports composite foreign keys though.