By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,949 Members | 1,838 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,949 IT Pros & Developers. It's quick & easy.

PHP MySQL object question

P: n/a
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
"CompanyName", "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.
Sep 14 '08 #1
Share this Question
Share on Google+
16 Replies


P: n/a
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.
Sep 15 '08 #2

P: n/a
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.
Sep 15 '08 #3

P: n/a
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
"CompanyName", "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*******@attglobal.net
==================

Sep 15 '08 #4

P: n/a
AqD
On Sep 16, 5:05*am, William Gill <nore...@example.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 ;)
Sep 16 '08 #5

P: n/a
AqD wrote:
On Sep 16, 5:05 am, William Gill <nore...@example.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 ;)
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*******@attglobal.net
==================

Sep 16 '08 #6

P: n/a
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?

Sep 16 '08 #7

P: n/a
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*******@attglobal.net
==================

Sep 16 '08 #8

P: n/a
AqD
On Sep 16, 6:16*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 16, 5:05 am, William Gill <nore...@example.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 ;)

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.
Sep 16 '08 #9

P: n/a
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.
Sep 16 '08 #10

P: n/a
AqD wrote:
On Sep 16, 6:16 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
>>On Sep 16, 5:05 am, William Gill <nore...@example.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 ;)
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.
That's one way to do it. There are many others.

But even here you don't need an ORM to do your work. It is quite easy
to do it yourself.

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

Sep 17 '08 #11

P: n/a
AqD
On Sep 17, 8:43*am, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqD wrote:
On Sep 16, 6:16 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 16, 5:05 am, William Gill <nore...@example.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 ;)
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.

That's one way to do it. *There are many others.

But even here you don't need an ORM to do your work. *It is quite easy
to do it yourself.
Easy but a waste of time.

Why bother to write code by yourself when you can just use some
frameworks?
Sep 17 '08 #12

P: n/a
AqD wrote:
On Sep 17, 8:43 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqD wrote:
>>On Sep 16, 6:16 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 16, 5:05 am, William Gill <nore...@example.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 ;)
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.
That's one way to do it. There are many others.

But even here you don't need an ORM to do your work. It is quite easy
to do it yourself.

Easy but a waste of time.

Why bother to write code by yourself when you can just use some
frameworks?
No waste of time at all. It takes me very little time to create the
classes I need for a database. I've got a lot of skeleton code handy.
But then I've been doing it for many years.

And my classes do what I need them to do efficiently. None of the extra
overhead of your ORM, and custom validation of data is very easy.

I suspect it takes me less time to create the classes from my skeletons
than it does you to implement the same code in Hibernate.

Products like Hibernate are good for beginning programmers; they are OK
for programmers with fair experience. But few experts I know use them.

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

Sep 17 '08 #13

P: n/a
AqD
On Sep 17, 8:43*am, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 16, 6:16 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 16, 5:05 am, William Gill <nore...@example.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 ;)
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.

That's one way to do it. *There are many others.

But even here you don't need an ORM to do your work. *It is quite easy
to do it yourself.
How easy it'd be to retrive a list of the Car(s) above and give each
of them correct class types and also retrieve the fields in derived
classes (but not in 'Car') when they're used?
Sep 18 '08 #14

P: n/a
AqD
On Sep 17, 8:43*am, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 16, 6:16 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 16, 5:05 am, William Gill <nore...@example.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 ;)
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.

That's one way to do it. *There are many others.

But even here you don't need an ORM to do your work. *It is quite easy
to do it yourself.
PS: have you read code in Hibernate or JDO implemetations?
Sep 18 '08 #15

P: n/a
AqD wrote:
On Sep 17, 8:43 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
>>On Sep 16, 6:16 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 16, 5:05 am, William Gill <nore...@example.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 ;)
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.
That's one way to do it. There are many others.

But even here you don't need an ORM to do your work. It is quite easy
to do it yourself.

How easy it'd be to retrive a list of the Car(s) above and give each
of them correct class types and also retrieve the fields in derived
classes (but not in 'Car') when they're used?
Quite easy, actually. That's what business objects are for.

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

Sep 18 '08 #16

P: n/a
AqD wrote:
On Sep 17, 8:43 am, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
>>On Sep 16, 6:16 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 16, 5:05 am, William Gill <nore...@example.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 ;)
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.
That's one way to do it. There are many others.

But even here you don't need an ORM to do your work. It is quite easy
to do it yourself.

PS: have you read code in Hibernate or JDO implemetations?
Yep. That's why I use my own classes.

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

Sep 18 '08 #17

This discussion thread is closed

Replies have been disabled for this discussion.