If you had a database-driven project to do from scratch which of these 3 routes would you take and why?

Well to be honest, I have never liked Class::DBI, it seems (from my feeble assessment, someone please correct me if I am wrong) that it is really just a thin layer over the database and not a lot more than a SQL generator coupled with a class generator. You are not really abstracting away the database, which is what Object-Relational Mapping is trying to acheive. Now, there is nothing wrong with this, it certainly can be a useful tool which can speed up development. But "Object-Relational", maybe not so much.

Real true object relational mapping is not just the one-object-per-row approach that many tools offer, but really a complex and transparent mapping of an class hierarchy to a relational storage format. This means that your class design comes first, and you figure out how to shoe-horn it into a relational database later (of course, as with all design, there will be some compromise too). Which means figuring out how all your class inheritance, delegation, aggregation, etc, etc, etc. should be represented relationally. Some tools try to do all this for you using class reflection and other such silliness. But, the problem I have always had with a lot of these ORM tools is that the DB design it ends up creating is a DBA's nightmare. And so my feeling has always been that a compromise needs to be struck based upon the requirements of the application. The result is that just about all the applications I have created of late use a combination of our in-house ORM tool for some parts, and DBI/raw-SQL for other parts. To use one or the other exclusively would have lead to either a lack of re-use in the parts that use the ORM, or a lack of performance in the parts that use the raw DBI/SQL, and I needed to have both to fill the requirements of those applications.

As for DBIx::RecordSet, I have never used it, so I cannot really say. But from a quick read of the docs, it too looks like your standard SQL-wrapped-in-an-object module. My guess is that Class::DBI would do much the same and give you more flexibility (althought maybe with a higher learning curve).

As for ACE, I have attempted to install it once or twice in hopes of playing around with it, but never managed to get it all working. It is an interesting looking thing for sure, but I can't say much more than that until I manage to get the time to install it right.

-stvn

In reply to Re: object-relational Perl programming: best practice or compromise? by stvn
in thread object-relational Perl programming: best practice or compromise? by metaperl

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.