ORM system

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

ORM system

Post by alex.barylski »

So i've pulled out some old ORM classes which I was working on a while back, which actually started as a SQL project I started years ago, but was then introduced to the idea of ORM by Arborint...so I mashed the two togather...

Just so I'm clear on what is actually going on and can possibly pin point where mine is different and possibly better...or worse :P

Can we start a disscussion on ORM?

I'd like to hear the positives and negatives and be specific...

I've heard and been told by some on here that ORM is good for trivial CRUD but anyting beyond is often too much for it to handle...

How does a traditional ORM perform CRUD operations...

Assuming I had a hierarchy like:

Code: Select all

CxUser (fname, lname, age)
  CxMember (user, pass)
Would this map to 2 seperate tables accordingly?

Do the CRUD functions cascade? So to insert into both tables using the CxMember object would I need to call just the CxMember INSERT function or would I call both?

How would the above ORM perform a multiple selection?

I have a idea of how I want my own to work and have spent a good deal of time contemplating how an existing ORM might work, but admittedly I have never read or looked into existing ORM solutions or the patterns themselves...

I'm looking for theory only, please no examples...like the ORM solution here in devnetwork...

Cheers :)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Assuming I had a hierarchy like:

Code: Select all

CxUser (fname, lname, age)
  CxMember (user, pass)
Would this map to 2 seperate tables accordingly?
Depends on your database mapping scheme and whether or not CxUser can be instantiated. PoEAA goes over the three main solutions in this manner: Concrete, Class and Single Table Inheritance.

Concrete inheritance has tables for each concrete class, and each table has a column that would be found in an instance of the class (so the `cxMember` class would have a fname, lname, age, user and pass column)

Single table inheritance meshes all possible member variables into one table. Unused columns are left blank.

Class table inheritance is the most non-redundant, but also requires the most joins: essentially, the table setup would look most like what you outlined above. Updating a record may need accessing multiple tables.

This isn't really ORM though...

http://en.wikipedia.org/wiki/Object-relational_mapping looks interesting.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

:Bump:

:P

I am amazed I didn't get a single reply to disscuss how ORM is implemented, what could be improved, etc...

So I'll get more specific...

ORM, that I'm building, I want it to basically control the DB through objetcs strictly...

If you change the class, when the object is contructed, it'll update (ALTER, etc) the database table accordingly...

Is this a role of OR/M typically? I suppose this would require using some kind of XML mapping file, mapping SQL types to member data...

I really like the idea of that, but I am unsure whther it's even within the boundries of OR/M and I'm too lazy to read further today anyways, so I figured I would ask...

How does OR/M manage to select mutliple tables at once?

How would it, technically perform a multiple table query???

Do you have to use 2 objects, specify search criteria (I assume by setting member data) and somehow perform an explicit JOIN or something???

Anyone interested in disscussing this??? :roll:
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

I am amazed I didn't get a single reply to disscuss how ORM is implemented, what could be improved, etc...
It's really complex, and some people think it's a lost cause. Personally, I think that the cost for automating the whole thing isn't really worth it, a Mapper supertype will do just fine.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Well, it's possible I just haven't developed enough of my own OR/M but I have put much thought into it and if I can get it to where I see it going, it would certainly not be a lost cause... :P

Something also I'd like ot know however, now were on the subject :P

When you design your objetcs, does the chicken come before the egg or visa versa...

Which on is the chicken and the egg??? :P

Basically, I usually (normal development without OR/M) start with designing a database schema, normalize it as best I can, then begin wrapping objects around the tables...

Is this the flow of things when working with ORM or do you ignore it and just jump straight into object discovery, which if the ORM does as I want, would update my DB schema anyways...

When mapping an object to a table, does there have to be a 1:1 relationship or can 2 tables be associated with a single object?

How would this be accomplished???
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

If your objects have a direct relationship to the tables, good for you. You could even use an ActiveRecord. ORM would probably be fairly easy to implement.

It's when the database drifts away from the model that ORM gets really complicated.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Your last sentance is where your losing me...can you explain with an example?

I've looked into Hibernate and ActiveRecord, admittedly not very long but enough to get the basic concept behind OR/M

I can see circumstances where OR/M wouldn't be fantastic, mostly in SELECTing or generating structural data, like that of a threaded forum or file structure...but I'm sure there are adhoc work arounds...

Again I havent' spent enough time developing mine to make any calls like this...

I can't see why, without proper planning, an ORM object couldn't keep a one to one relationship with DB tables it represents...

In fact, the with little I understanding I have of the subject I would argue that it probably make practical sense to keep your ORM objects and tables tightly associated...???

Although I do remember (last time I started this project) running into the problem of two tables using a single object, because of performance issues of 2 seperate objects...

For technical reasons and in a relational perspective it made sense to use 2 tables, but from an object perspective, it made sense to use only...

This is causing some impedence on my part...but I'm looking into work arounds...
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Here is a patent for a technique that sounds quite similar to mine..

In which case, what a rediculous patent...I have not formally studied the topic, only read a handful of articles and "thought" about what ORM really meant and began coding away...

Although I'm not close to completing it, one in theory could be generated from the other...

By the sounds of things, thats what their patenting???

Anybody care to try and decrypt what their saying and give it to me in their own words...being as terse as possible???

http://patft.uspto.gov/netacgi/nph-Pars ... PN/6101502

Cheers :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

A couple of random thought. First is that when you need ORM your write and ORM ... and that's not very often in PHP. Second, your OP mentioned CRUD which is usually very simple single table stuff -- so ORM is massive overkill. And ... what are you thinking both reading and sending other to read Patent gobblygook? That is the worst source of ORM info I have seen in a while.

And finally,what is your problem with paragraphs? They are a best practice that works. ;)
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

arborint wrote:A couple of random thought. First is that when you need ORM your write and ORM ... and that's not very often in PHP. Second, your OP mentioned CRUD which is usually very simple single table stuff -- so ORM is massive overkill. And ... what are you thinking both reading and sending other to read Patent gobblygook? That is the worst source of ORM info I have seen in a while.

And finally,what is your problem with paragraphs? They are a best practice that works. ;)
I lost you, what do you mean? When I need ORM I write ORM? Why is it not often in PHP? I use RDBMS far more in PHP than any other language I develop software in...so when would one use ORM?

CRUD as I understand it, is Create, Rename, Update, Delete, but I was never under the impression they were limited to only single tables... :?

Regardless, how is ORM overkill? As I understand it, it's the mapping of a relational data store to an OOP paradigm.

It hides the linera details from you giving the illusion of workign with objects. It's never intended to increase performance or development times, but rather change the methodology or apparoch to software development...

Much like switching from C to C++ wasn't intended to speed up software development, except through code reuse, nor was C++ intended to improve execution speeds...but it's still the better paradigm...I think most would agree (except in the case of drivers, Kernel, etc)

The idea of working with objects generally has a positive effect on developers once given a proper chance...
And ... what are you thinking both reading and sending other to read Patent gobblygook? That is the worst source of ORM info I have seen in a while
Again, I'm tired so pardon me if this is obvious, but you lost me again :oops:

Reading and sending??? After reading that patent I was under the impression it was patenting the idea of using code to generate/update DB schema or visa-versa...

Which is exactly what my ORM class does...using some kind of mapping file or not, the point is, thats the impresion I got from reading that patent...

Cheers
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Hockey wrote:Regardless, how is ORM overkill? As I understand it, it's the mapping of a relational data store to an OOP paradigm.
ORM as I understand the usage of the term describes system where you only deal with objects and the persistance mechanism behind them is handled separately. Others can correct my misconception.

I think my larger point as to the rarity of ORM system in PHP is that an ORM is one solution to a fairly common problem, but not the only one. In PHP that kind of problem is commonly not solved with an ORM system. There are many reasons why ... but mainly I think it is just not in the general PHP spirit. You can either simplify your application code by writing complex subsystem code beneath it ... or you can just write simpler application code.

If you are interested in an new and interesting take on O/RM you might want to read this article which is also an interesting coverage of the Vietnam War for those who don't know much about it (an which is probably applicable to Iraq today). The article is a little long but he really gets to the essence of why O/RM is a slippery slope of diminishing return -- and give a number of simpler types of O/RM that can make more sense.

http://blogs.tedneward.com/PermaLink,gu ... 1d91f.aspx
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

I'll look into it :)

Thanks
wei
Forum Contributor
Posts: 140
Joined: Wed Jul 12, 2006 12:18 am

Post by wei »

Basically, I usually (normal development without OR/M) start with designing a database schema, normalize it as best I can, then begin wrapping objects around the tables...
1) If you prefer that the database posseses (sp?) ACID properties, you would probably have foreign keys, constraints, views, and store procedures.
this the flow of things when working with ORM or do you ignore it and just jump straight into object discovery, which if the ORM does as I want, would update my DB schema anyways
2) From this point of view, you want to work with only objects, not caring about 1), there are issues of object graphs, collections and hiearchical relationships

as it was pointed out by http://blogs.tedneward.com/PermaLink,gu ... 1d91f.aspx

there is a fairly large mismatch between 1) and 2)

So it depends on which point you wish to tackel the problem from, and if you tried to do both it will probably be a mess.

For solution to 2), the ezpdo implementation seems to fit, as it actually manages the table creation and relationships without seeing the database. However there are draw backs, as it tends to like to issues many more queries than it may be necessary (may be they can optimize more, but that gets very difficult is some cases)

For solution to 1), there is the SQLMap DataMapper (this is my implementation of the Ibatis SQLMap). This point of view maps data from the database to php objects or primatives. You have to write the sqls, write the mappings (optional, by the default is limited). What you get in return are objects populated with the data you queried. The draw back here is that you need to write SQL, and mappings. The advantages are the with 1 query, you can return a fairly complicated N:M relationship collection object.

http://trac.pradosoft.com/browser/trunk ... ess/SQLMap
http://xlab6.com/p3/demos/sqlmap/?page= ... BigPicture
Post Reply