Tilted Forum Project Discussion Community  

Go Back   Tilted Forum Project Discussion Community > Interests > Tilted Technology


 
 
LinkBack Thread Tools
Old 08-24-2004, 06:13 AM   #1 (permalink)
Insane
 
trache's Avatar
 
[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
trache is offline  
Old 08-24-2004, 06:45 AM   #2 (permalink)
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.
magua is offline  
Old 08-24-2004, 09:25 AM   #3 (permalink)
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);

SinisterMotives is offline  
Old 08-24-2004, 09:50 PM   #4 (permalink)
Insane
 
trache's Avatar
 
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
trache is offline  
Old 08-25-2004, 06:35 PM   #5 (permalink)
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..
SinisterMotives is offline  
 

Tags
access, data, objects, php or sql

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -8. The time now is 09:47 PM.

Tilted Forum Project

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Search Engine Optimization by vBSEO 3.6.0 PL2
© 2002-2012 Tilted Forum Project

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360