Problems? Is your data what you think it is? | |
PerlMonks |
Re: Creating a model of a bad databaseby siracusa (Friar) |
on Dec 13, 2006 at 20:04 UTC ( [id://589667]=note: print w/replies, xml ) | Need Help?? |
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:
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 Section
Seekers of Perl Wisdom
|
|