Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^2: Class::DBI not intuitive

by stvn (Monsignor)
on Jul 27, 2004 at 19:59 UTC ( [id://377845]=note: print w/replies, xml ) Need Help??


in reply to Re: Class::DBI not intuitive
in thread Class::DBI not intuitive

I very much agree with you that OO->Relational mapping tend to work much better for small applications where performance is not critical. But that is not to say that it cannot be used within larger more performance critical applications. We tend to use our own Object Persistence/OO->Relational tools for things like the user-administration portion of our reporting applications where performance is not critical, while using optimized SQL/DBI code for the reports themselves. It greatly simplifies the code in the user-admin portion of the site and makes it much easier to maintain, which works out well cost-wise too since that portion of the site it not really what our customers care about.

A lot of smaller applications can decompose their data into a class-to-table relational structure.

One misconception about OO->Relational mapping tools is that they are bound to class-to-table relationships. This may be true of Class::DBI (I don't know I have never used it), but the more generalized OO->Relational mapping patterns are not confined to that basic a relationship. Simple tools will map table-column to class-field, and this is only so useful. A more complex tool (or possibly custom written code) could use a longer more complex query with multiple table joins to return a result set which can then be mapped into an object. So now your class-fields map to columns in multiple tables. Of course this gets much more complicated with INSERTs, UPDATEs and DELETEs. This may require a lot of up-front work, but IMO that is the right kind of laziness.

I recently picked up a book called Patterns of Enterprise Application Architecture by Martin Fowler. It's examples are mostly in Java or C#, but the patterns themselves are language agnostic. It has a number of patterns dealing with OO->Relational mapping, you might want to check it out, very interesting stuff.

-stvn

Replies are listed 'Best First'.
Re^3: Class::DBI not intuitive
by dragonchild (Archbishop) on Jul 29, 2004 at 13:24 UTC
    A more complex tool (or possibly custom written code) could use a longer more complex query with multiple table joins to return a result set which can then be mapped into an object. So now your class-fields map to columns in multiple tables.

    This may be a dumb question, but how is this different from the business object mapping that I referred to?

    The benefits of CDBI and similar tools (like Hibernate for Java) is that they do a lot of work for you, but the tradeoff is that the work is generally mediocre. In the places where mediocre is good enough, then it would be foolish to do that work by hand. (The other app in my office uses Hibernate, specifically for that reason.)

    But, in those places where you need to write custom code to map your objects (which are presumably business-oriented) to the database (which is presumably storage-oriented), you don't have an OO->Relational tools gain.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

      This may be a dumb question, but how is this different from the business object mapping that I referred to?

      It may not really be that different. It all depends upon how you go about it.

      Our internal OO->relational system uses 2 classes for each object. One is the class which fetches/updates/inserts data into the DB. The other is the object (business object) we use in the application. The only thing these two objects need to share is a common set of attributes (object fields, and table columns (or multiple table columns)). The main heart of the system is a mediator object which handles the interaction of these 2 classes. The result is that while we don't get as much for free as you might from something like Class::DBI, with a little more up front work, you can reap many more benefits. The result is that easy things are a little harder than normal, medium things are not much harder than easy things, and complex things are reasonably proportional to their own complexity. From what I have seen with many OO->Relational mappers, the complexity of the implementation rises at a much faster rate than the complexity of the problem itself, and so they can quickly become more of a burdon then an asset.

      Now, of course, our system is not perfect, it has its flaws, in particular its very inefficient with large tables (many columns, not many rows). And it cannot automagically handle joins, you have to hand-code the SQL (although it can handle foreign key/link relationships as lazily loaded objects). It is also still pretty much specific to much of the database work we do, so it doesn't handle BLOBs (although it could be made to quite easily, we have just never had a need), and it has only really be tested on MySQL and PostgreSQL.

      Some tools may require more custom code than others, but sometimes that extra up-front work is worth it, if you can get some other things for free. I guess my point is that the tools dont always have to be inefficient, and it doesn't have to be an all or nothing deal.

      -stvn

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (6)
As of 2024-03-28 21:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found