PHP MySQL object question

[William Gill]

I am writing some new editing pages for a db using php. I want to use
an object approach for the underlying MySQL tables, and the edit page
will display related data from several tables. I am thinking about
creating a class for each table, and then a class for the "view." So, a
class (Client) for the db.client table would have members like
"CompanyNam e", "ID", etc. The class for the db.address table (address)
would have members like "City", "State", "zip", etc. Then the class for
the view would have members that are objects like Client, address, etc.
Can anyone give me any pros and cons of this approach, especially
since I will also need to create session variables to store and compare
data before and after editing.

[boxoft]

Hi,

Ruby on Rails implements ORM very well.

As for PHP,you might be interested in http://www.doctrine-project.org/.

Regards,
Box
boxoft...help people, serve people.

[William Gill]

boxoft wrote:

Hi,

Ruby on Rails implements ORM very well.

As for PHP,you might be interested in http://www.doctrine-project.org/.

Regards,
Box
boxoft...help people, serve people.

Both interesting, but I'm at a point right now where learning a new
language, or application would be next to impossible.

[Jerry Stuckle]

William Gill wrote:

I am writing some new editing pages for a db using php. I want to use
an object approach for the underlying MySQL tables, and the edit page
will display related data from several tables. I am thinking about
creating a class for each table, and then a class for the "view." So, a
class (Client) for the db.client table would have members like
"CompanyNam e", "ID", etc. The class for the db.address table (address)
would have members like "City", "State", "zip", etc. Then the class for
the view would have members that are objects like Client, address, etc.
Can anyone give me any pros and cons of this approach, especially since
I will also need to create session variables to store and compare data
before and after editing.

That's one way to do it, and I use it quite a bit for low level
operations on the database. In more complicated applications I layer a
business object on top of the database objects.

Don't try to store large objects in your session, though. Better to
store id's in the session rather than the entire object.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[AqD]

On Sep 16, 5:05*am, William Gill <nore...@exampl e.comwrote:

boxoft wrote:

Hi,

Ruby on Rails implements ORM very well.

As for PHP,you might be interested inhttp://www.doctrine-project.org/.

Regards,
Box
boxoft...help people, serve people.

Both interesting, but I'm at a point right now where learning a new
language, or application would be next to impossible.

It's easier to learn & use ORM rather than to write object<->db
interface by yourself ;)

[Jerry Stuckle]

AqD wrote:

On Sep 16, 5:05 am, William Gill <nore...@exampl e.comwrote:

>boxoft wrote:

>>Hi,
Ruby on Rails implements ORM very well.
As for PHP,you might be interested inhttp://www.doctrine-project.org/.
Regards,
Box
boxoft...he lp people, serve people.

Both interesting, but I'm at a point right now where learning a new
language, or application would be next to impossible.

It's easier to learn & use ORM rather than to write object<->db
interface by yourself ;)

Nonsense. Writing simple db objects such as this is quite easy.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[William Gill]

Jerry Stuckle wrote:

That's one way to do it, and I use it quite a bit for low level
operations on the database. In more complicated applications I layer a
business object on top of the database objects.

Not sure what you mean by "business object?"

>
Don't try to store large objects in your session, though. Better to
store id's in the session rather than the entire object.

Since I am only dealing with one composite record at a time (editing) I
was planning to store the original field data for before and after
comparison to determine when and where updates are needed. (12 - 20
fields, from 4 or 5 tables) I could do it as separate session
variables, but since each table record will have an associated object,
why not just store them that way? Or are you suggesting save the id in
a session variable, then re-select the db record and compare fields
(with incoming data) to see which need updating?

[Jerry Stuckle]

William Gill wrote:

Jerry Stuckle wrote:

>That's one way to do it, and I use it quite a bit for low level
operations on the database. In more complicated applications I layer
a business object on top of the database objects.

Not sure what you mean by "business object?"

Business objects are another OO layer on top of the database. They
server to further decouple the application code from the data storage.

For instance, a business object may get information from several
different tables, and when you update the data in the business object,
it updates the underlying tables.

>>
Don't try to store large objects in your session, though. Better to
store id's in the session rather than the entire object.

Since I am only dealing with one composite record at a time (editing) I
was planning to store the original field data for before and after
comparison to determine when and where updates are needed. (12 - 20
fields, from 4 or 5 tables) I could do it as separate session
variables, but since each table record will have an associated object,
why not just store them that way? Or are you suggesting save the id in
a session variable, then re-select the db record and compare fields
(with incoming data) to see which need updating?

Just store the id and later just update the data. MySQL is smart enough
not to update data which doesn't need to be changed. Or, if you don't
have all of the data in the object, reselect the row, update the object
then update the database. Unless your system is heavily used, chances
are the original row will still be in the database's cache and retrieval
will be very quick.

Of course, this is assuming no one else will be changing the data in the
meantime. If they are, you have to save the old data (the session would
work) and the second time around, fetch the data again. Compare the
saved data with that in the object; if there is a difference you need to
determine if it's important or not (i.e. if someone else updated column
'a' and you're updating column 'b', it's probably not a problem).

But just beware that when you save the object to the $_SESSION array,
PHP has to serialize it, then unserialize it later. This can be a bit
of overhead. And it can affect performance if your system is busy.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[AqD]

On Sep 16, 6:16*pm, Jerry Stuckle <jstuck...@attg lobal.netwrote:

AqDwrote:

On Sep 16, 5:05 am, William Gill <nore...@exampl e.comwrote:

boxoft wrote:
Hi,
Ruby on Rails implements ORM very well.
As for PHP,you might be interested inhttp://www.doctrine-project.org/..
Regards,
Box
boxoft...hel p people, serve people.
Both interesting, but I'm at a point right now where learning a new
language, or application would be next to impossible.

It's easier to learn & use ORM rather than to write object<->db
interface by yourself ;)

Nonsense. *Writing simple db objects such as this is quite easy.

Simple objects, yes.

How about this:

class Car
class SpecialCar extends Car
SELECT * FROM Car where color = 'red';

The list of result should include SpecialCar(s) and have them in
correct type (and all derived classes from 'Car').

And the driver (another class) and other properties in 'Car' should be
fetched, too. Being fetched with the result list (by join) or later
when they're actually accessed. The laziness of related objects must
also be customized, in model classes and/or in query.

And a .save method to save this object and all related ones (also
check for modification), and make inserts if needed.
That is what ORMs like Hibernate are supposed to do for you.

[William Gill]

Jerry Stuckle wrote:

William Gill wrote:

>Jerry Stuckle wrote:

>>That's one way to do it, and I use it quite a bit for low level
operations on the database. In more complicated applications I layer
a business object on top of the database objects.

Not sure what you mean by "business object?"

Business objects are another OO layer on top of the database. They
server to further decouple the application code from the data storage.

For instance, a business object may get information from several
different tables, and when you update the data in the business object,
it updates the underlying tables.

I thought so. This is in essence what I am doing.

Just store the id and later just update the data. MySQL is smart

enough

not to update data which doesn't need to be changed...

I was unaware MySQL could/would make such a determination. Now that I
think of it, the not changing the timestamp is the only reason it would
matter for what I'm doing.

>...Or, if you don't
have all of the data in the object, reselect the row, update the object
then update the database. Unless your system is heavily used, chances
are the original row will still be in the database's cache and retrieval
will be very quick.

Of course, this is assuming no one else will be changing the data in the
meantime. If they are, you have to save the old data (the session would
work) and the second time around, fetch the data again. Compare the
saved data with that in the object; if there is a difference you need to
determine if it's important or not (i.e. if someone else updated column
'a' and you're updating column 'b', it's probably not a problem).

But just beware that when you save the object to the $_SESSION array,
PHP has to serialize it, then unserialize it later. This can be a bit
of overhead. And it can affect performance if your system is busy.

I know, but, at least in the current case, the performance hit and/or
simultaneous user updating aren't an issue.