Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re: Creating a model of a bad database

by siracusa (Friar)
on Dec 13, 2006 at 20:04 UTC ( [id://589667]=note: print w/replies, xml ) Need Help??


in reply to Creating a model of a bad database

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).

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://589667]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2024-03-29 14:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found