[Dbix-class] DBIx::Class as an Object-Relational mapper

[techwiseman-perlml at yahoo.com]

On 3/15/06 11:49 AM, John Siracusa wrote:
 > On 3/15/06 2:12 PM, Brandon Black wrote:
> > There are a lot of similarities between good relational database
> > design and good OO design, but I think the foundation of any good
> > application is a solid relational data model first; the code is a
> > second-class citizen comparatively.
> >
> > An ORM (DBIx::Class or otherwise) is to me just a convenient OO
> > interface for manipulating a relational database, rather than
> > something that should try to "hide" the RDBMS in an seemingly-OO-like
> > mask of smoke and mirrors.
> > 
> > That's just my personal opinion though, and I'm probably in the
> > minority in the world (and this list) right now.  :)
>
> I think you're in the majority in both (and I agree with you, FWIW).  I can
> see the attraction of the alternate approach, but it's certainly not as
> well-understood as the one you describe.
>
> -John

 Well, like I said, I have been researching the issue and feel I can identify with both sides of the issue. My acedemic background (and most of my work experience) is OOP, so I am rather biased in that direction, but I have been around DBs and DBAs and heavy DB users enough to see the relational side of the arguments also.  While it puts me off a bit to look at an OO system as a second-class citizen, I can see how having data exposed to "user" examination/tampering puts a very different spin on things.  That's not to say we can't try to controt an RDBMS over an OO knee with triggers and the like, to make it behave like an OO system, but I strongly agree that's using the wrong tool for the job. The reasons I'm advocating imposing an OO spin on the RDBMS are:
 
 1) Our database is in some severe need of normalization anyway, and imposing OO upon it will accomplish most of the important things that normilization would in our case.
 
 2) Design simplicity:  While pushing the OO concept all the way back to the RDBMS will cause some headaches, I believe it will prevent having to design the RDB and OO sides of the system separately, and (hopefully) save ALMOST half the work.
 
 3) (And most importantly) Selling the idea of needing two designs to non-technical management appears a much more daunting task than sellint the idea of a UNIFIED design.
 
 If either of you have suggestions that address any of the above, I'm most anxious to hear them.
 
 Thank you,
 
 -Loren