[PHP/SQL] Data Access Objects - Tilted Forum Project Discussion Community

trache · 08-24-2004, 06:13 AM

I consider myself a fairly competent PHP programmer. I have a decent concept of Object Oriented Programming (putting into practice is a different story), but with this new problem, I'm beginning to go bonkers:

Everyone knows the easiest way to start OO database work is to create a database object that actually performs the queries etc. PEAR:

B does this, and I wrote my own that will interface with MySQL and PostgreSQL. Methods like setQuery(), Query() and getNumRows() are present.

So the next step: Every row in a certain table is used as an object. There are private variables corresponding to each field in the table to which the object belongs with public methods to access them. Easy enough hmm?

PHP cannot know my table schema (unless there is a way, please tell me), so I am forced to make a discrete object for every one of them. Sure I can make a generic "table" object, but I still have to name that table and put its fields into some sort of array for the queries to be populated properly. That's where I fall into a trap: I want to decrease the amount of typing and programming I have to do, but it looks as though this is almost impossible.

So what happens when I put JOINS into the mix? How do I handle those properly with objects? How would I properly have two table objects and still be able to define the relationship between them so that the actual database query might go smoothly?

I think I may just go back to procedural programming.

I'm pulling my hair out... help!

Wes

magua · 08-24-2004, 06:45 AM

Don't go overboard on the OO. Figure out if and when you need the objects, and use those. And for god's sake, don't go with the "one object per row per table" paradigm unless it actually fits. If you're thinking about JOINing tables together, it doesn't fit, and trying to make it fit will only end up hurting. Design your objects based on how you plan to use them in code, not based on the database schema.

If all your objects are doing is holding the values from the table, for instance, then it's doubtful you need them at all; there's no benefit gained from querying the database, creating (and filling) a bunch of objects, and then getting the data from the objects when you can just get it from the database directly.

SinisterMotives · 08-24-2004, 09:25 AM

Do go overboard on OOP. I used to have the attitude of "why should I instantiate all these objects for a script that will run for less than a millisecond?" and now I know why. It helps my programs practically write themselves.

The thing you need to ditch is MySQL, not OOP. If you want to persist objects, use serialize() and unserialize() with flatfiles. I've been doing stuff like this for a year now, and my scripts are blazing fast:

PHP Code:


			


class AnObject {



 var $unique_id;



 function AnObject($unique_id) {

  $this->unique_id = $unique_id;

  $this->save();

 }

 

 function save() {

  $fp = fopen($this->unique_id . '.dat','w');

  $data = serialize($this);

  fwrite($fp,$data);

  fclose($fp);

 }



}



// The following assumes $unique_id is provided

// and that it refers to a specific persisted object.



$filename = $unique_id . ".dat";

if (file_exists($filename)) {

 $my_obj = unserialize(file_get_contents($filename));

}

else {

 $my_obj = new AnObject($unique_id);

}

trache · 08-24-2004, 09:50 PM

Sinister:

Is there any way you can move that code over to support an SQL backend? What if you wanted to join two tables (or select two flatfiles with a relation to one another on your filesystem?)

SinisterMotives · 08-25-2004, 06:35 PM

You could store each serialized object in a database and manipulate the relations among them with SQL, but the serial data itself would be a string representing the object's native PHP member variables. For example, to merge two "tables", you would have to deserialize the objects and operate on their member variables (multidimensional arrays in this case). I'm working on a PHP recordset class that mimics some of the functionality of a database server, but a full SQL implementation would be gross overkill for the application I'm using it in.

08-24-2004, 06:13 AM	#1 (permalink)
trache Insane	[PHP/SQL] Data Access Objects I consider myself a fairly competent PHP programmer. I have a decent concept of Object Oriented Programming (putting into practice is a different story), but with this new problem, I'm beginning to go bonkers: Everyone knows the easiest way to start OO database work is to create a database object that actually performs the queries etc. PEAR:B does this, and I wrote my own that will interface with MySQL and PostgreSQL. Methods like setQuery(), Query() and getNumRows() are present. So the next step: Every row in a certain table is used as an object. There are private variables corresponding to each field in the table to which the object belongs with public methods to access them. Easy enough hmm? PHP cannot know my table schema (unless there is a way, please tell me), so I am forced to make a discrete object for every one of them. Sure I can make a generic "table" object, but I still have to name that table and put its fields into some sort of array for the queries to be populated properly. That's where I fall into a trap: I want to decrease the amount of typing and programming I have to do, but it looks as though this is almost impossible. So what happens when I put JOINS into the mix? How do I handle those properly with objects? How would I properly have two table objects and still be able to define the relationship between them so that the actual database query might go smoothly? I think I may just go back to procedural programming. I'm pulling my hair out... help! Wes __________________ "You looked at me as if I was eating runny eggs in slow motion." - Gord Downie of The Tragically Hip

08-24-2004, 09:25 AM	#3 (permalink)
SinisterMotives Junkie	Do go overboard on OOP. I used to have the attitude of "why should I instantiate all these objects for a script that will run for less than a millisecond?" and now I know why. It helps my programs practically write themselves. The thing you need to ditch is MySQL, not OOP. If you want to persist objects, use serialize() and unserialize() with flatfiles. I've been doing stuff like this for a year now, and my scripts are blazing fast: PHP Code: class AnObject { var $unique_id; function AnObject($unique_id) { $this->unique_id = $unique_id; $this->save(); } function save() { $fp = fopen($this->unique_id . '.dat','w'); $data = serialize($this); fwrite($fp,$data); fclose($fp); } } // The following assumes $unique_id is provided // and that it refers to a specific persisted object. $filename = $unique_id . ".dat"; if (file_exists($filename)) { $my_obj = unserialize(file_get_contents($filename)); } else { $my_obj = new AnObject($unique_id); }

08-24-2004, 09:50 PM	#4 (permalink)
trache Insane	Sinister: Is there any way you can move that code over to support an SQL backend? What if you wanted to join two tables (or select two flatfiles with a relation to one another on your filesystem?) __________________ "You looked at me as if I was eating runny eggs in slow motion." - Gord Downie of The Tragically Hip

08-25-2004, 06:35 PM	#5 (permalink)
SinisterMotives Junkie	You could store each serialized object in a database and manipulate the relations among them with SQL, but the serial data itself would be a string representing the object's native PHP member variables. For example, to merge two "tables", you would have to deserialize the objects and operate on their member variables (multidimensional arrays in this case). I'm working on a PHP recordset class that mimics some of the functionality of a database server, but a full SQL implementation would be gross overkill for the application I'm using it in. Last edited by SinisterMotives; 08-25-2004 at 06:40 PM..

08-24-2004, 06:45 AM	#2 (permalink)
magua Tilted	Don't go overboard on the OO. Figure out if and when you need the objects, and use those. And for god's sake, don't go with the "one object per row per table" paradigm unless it actually fits. If you're thinking about JOINing tables together, it doesn't fit, and trying to make it fit will only end up hurting. Design your objects based on how you plan to use them in code, not based on the database schema. If all your objects are doing is holding the values from the table, for instance, then it's doubtful you need them at all; there's no benefit gained from querying the database, creating (and filling) a bunch of objects, and then getting the data from the objects when you can just get it from the database directly.