First let me say that I'd hesitate to use any ORM in a plain CGI environment where the entirety of the Perl code has to be loaded into memory on every request, and is then discarded at the end. (And forget about dynamically loading table information from the database, since that'd have to be done on every request.) In such an environment, startup time is critical. Adding more, bigger Perl modules to load is not a good thing.

But perhaps there are other, larger performance issues in your case and you think you can afford to load another few thousand lines of Perl code on every request. If that's the case, then an ORM can help you, but it will probably not get you all the way to your goal of "refactor[ing] the awful database design, [and] building a clean object layer (the model) on top."

As has been noted, it's not retrieving data that's the problem. Modern Perl ORMs can fetch data from multiple tables simultaneously using JOINs and the like. The problem is going in the other direction: insert, update, and delete operations on a single Perl object mapping to an arbitrarily complex series of inserts, updates, and deletes in the database across many tables.

If your database has very flexible updatable views, and you can get by just using those, then maybe you can point your ORM of choice at the views and be all set. But most databases have severe limitations on updatable views, so this solution probably won't get you all of the way.

The solution that I think has the most promise is this:

  1. Pick an ORM to front all of your existing, poorly factored tables.
  2. Write another layer of your own code to provide the "real" interface that you will use. This layer should use the ORM to do its dirty work, but need not have any relation to the ORM API (but see below).

I think that's the best way to really isolate the ugly db design from your "end user" code. You still get the benefits of the ORM in that you don't have to hand-write SQL or deal with the vagaries of column data formatting and so on, but you maintain complete independence of the API and the db design. As you refactor the database, you should eventually be able to make this top layer API a trivial/automated wrapper for the underlying ORM (as the tables begin to match up better with the idealized top-level classes).

In reply to Re: Creating a model of a bad database by siracusa
in thread Creating a model of a bad database by Ovid

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.