|
in reply to Class::DBI not intuitive
CDBI is an example of an object-relational mapping system. One thing you may be stumbling over is that this is most definitely not the best solution in many cases. (In fact, some may say that object-relational mapping is usually a good indication your database is poorly designed, but that's another discussion. Google Fabian Pascal for more info.)
Many applications instead require a business concept to relational mapping, where you have database accessors that provide business-model API calls, regardless of the underlying architecture. CDBI is not intended to solve this problem. In fact, using it in this case would cause you nothing but headaches trying to fit a perfectly good square peg into a round hole.
That said, CDBI is very good when it's used where it's meant to be used. A lot of smaller applications can decompose their data into a class-to-table relational structure. This isn't to say that CDBI is only useful for smaller applications. It's just that most of the examples I've seen where CDBI really shines are for smaller things like picture albums and CDDB-type MP3 lookups. I'm sure there are a lot of larger enterprise-level apps that are perfectly happy using CDBI for their RDBMS access.
I've never worked on an app that would have benefitted from it, but I also tend to work on apps that do a lot of custom reporting. While CDBI would help the development effort, I also have a lot of performance constraints that CDBI would miss unless I threw a ton of hardware at it. In my current app, for example, every single report (with a few exceptions) has to run in under 5 seconds, no matter what load or what the SQL looks like. Period. CDBI has too much overhead and innefficiency built in to be useful there, even if the syntactic sugar would be nice.
------
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
|
Re^2: Class::DBI not intuitive
by Your Mother (Archbishop) on Jul 27, 2004 at 06:02 UTC
|
While quite true that there is a performance compromise with CDBI, it can shave a week off of the development of a one-man project easily. I absolutely love it and would be lost (well, deeper into carpal tunnel country) without it. The regular and thoughtful indexing and optimization of the underlying DB can help make up for some of trade-off too.
| [reply] |
Re^2: Class::DBI not intuitive
by demerphq (Chancellor) on Jul 27, 2004 at 18:41 UTC
|
This is a node that has really touched on the issues that have made me disinclined to go down the CDBI route. But i have to admit i'd really like to hear you summarize this more cogently. I did do a search on Fabian Pascal but I think an article on the subject by yourself would be a very worthy meditation.
All I can say is that every time ive looked into CDBI it seems appropriate for fairly naive DB's but for serious work it seems totally unsuitable for handling complex relationships and business logic. Your comment about object/record class/table mappings really seems to encapsulate the problems I have. Its extremely unusal for me to have any such mapping, in fact its much more common to have objects be represented as a derived amalgamation of many records from many tables.
Anyway, I really hope you meditate on this.
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply] |
Re^2: Class::DBI not intuitive
by stvn (Monsignor) on Jul 27, 2004 at 19:59 UTC
|
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.
| [reply] |
|
|
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
| [reply] |
|
|
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.
| [reply] |
|
|
