Fetching all rows in database table - the OOP way?

[eluser]medvind[/eluser]
I am quite new to OOP and to the MVC way of thinking and I'm curious about one thing.

I have a model for each database table. There are cross-references in the tables, so that for instance order.customer_id points to customer.id.

When fetching all rows in a database table, for instance, 'order', and to fetch the associated information like the customer's name and address, it seems most efficient to do a detailed, joined database query to fetch all fields at once. However, I've gotten the impression that I should do everything with objects for it to be "real" OOP. So then I would have to make an array of order objects which in turn would create a customer object each to fetch all data. This seems to me like a huge waste of resources, but maybe there is a point to it?

Maybe I've misunderstood what should and what should not be done with objects?

[eluser]jedd[/eluser]
Hi medwind,

Remember that you are allowed to do whatever you like .. it's just a framework. Having said that, there are often right and wrong ways of doing stuff .. so never assume that because something is tricky that it's bad.

I don't subscribe to the one-table to one-model approach, mostly because of the problem of tying multiple tables together with my queries. Instead I have a model that owns a collection - a logically grouped set - of tables in my database. And I never pull objects out - instead it's always arrays (row_array() or result_array()).

The 1:1 / table:model relationship is more a true AR thing, than an OOP thing. If it's any consolation, PHP doesn't let you do true OOP anyway. Most people's CI code I've seen tends to lean even further from it (Model obects are not created for each new entity, but are treated more as just a database interface, or a library).

[eluser]medvind[/eluser]
jedd: Thanks for your kind reply!

I know I can do this any way I want, but I would like to learn better design and conding practices while I'm at it

Maybe your way of doing things is a bit better than mine. I would like to hear what others think/do as well. I figure there might be ways which I haven't thought of yet...

[eluser]adamp1[/eluser]
The way you mention sounds very like ORM. Basicly objects represent rows in the database. Now of course this can mean combining rows from different tables (linked by relations).

There are some in the Ignited code part of the forum, but the downside is they can be resource heavy.

The other way is custom SQL code to get what you want, in the form you want. Now this is good for large amounts of data since you won't be creating a load of objects you won't maybe use, but it will mean you may re-write the same SQL code (in which case you may need to refacto things)

[eluser]kgill[/eluser]
I'm the same as jedd, 1 model to 1 table is pointless in my opinion because you have to do a lot more on the PHP side of things just to make stuff work when a simple query would solve the problem. My models interface whatever tables they need to represent the object I'm working with. Really, isn't that the whole point of a model, to provide an interface to the data without needing to understand the underlying data structure. So I have a controller that just calls, student->getGrades($stu_id) and it gets what it needs, it shouldn't have to know that you have to hit 4 tables to get that data.