Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Tie::DBI vs Class::DBI

by tlm (Prior)
on Aug 20, 2005 at 11:41 UTC ( #485375=perlquestion: print w/replies, xml ) Need Help??
tlm has asked for the wisdom of the Perl Monks concerning the following question:

Dear monks,

I'm trying to decide between Tie::DBI and Class::DBI, and I would like to know your opinions about the relative merits of these two choices. (I'm leaning towards Tie::DBI, because it looks more straightforward, but the fact that Class::DBI appears to be far more popular makes me wonder if I'm missing something.)

Thanks in advance.

the lowliest monk

Replies are listed 'Best First'.
Re: Tie::DBI vs Class::DBI
by davidrw (Prior) on Aug 20, 2005 at 12:59 UTC
    Taking a quick read through the Tie::DBI pod, it looks like it doesn't support any of the relationships that Class::DBI does such has has_a and has_many. Also, it seems like CDBI's search() method is better than TDBI's select_where() method, and also CDBI has support for custom queries via set_sql but w/TDBI you just jet the dbh() to do it all yourself. TDBI docs also warn of performance concerns (but as for a direct TDBI-CDBI benchmark, i can't say). Another significant difference is that TDBI ties you to a hash, while CDBI provides objects to work with and all the obvious benefits that come with it (can't mispell hash keys, accessors/mutators, inheritance, custom methods, etc). Also note that CDBI has further support for specific databases in the Class::DBI::* modules (Class::DBI::Pg, Class::DBI::MSSQL, Class::DBI::mysql, etc), as well as Plugins. Class::DBI will also be far more supported by the mailing list and the wiki.

    To summarize, I would say that TDBI is a lot more limited, and only consider it if your needs are very limited (just a couple/few unrelated tables), and even then I personally would still use CDBI.

    Update: Summary bulletin points of things CDBI has that TDBI doesn't:
    • relationships (has_a and has_many)
    • search() better than select_where()
    • custom queries (set_sql)
    • better performance??
    • provides an object, not just a hash
    • db-specific support in the Class::DBI::* modules
    • Plugins
    • Support via active mailing list and wiki
      this will help you to compare:
Re: Tie::DBI vs Class::DBI
by CountZero (Bishop) on Aug 20, 2005 at 14:43 UTC
    And don't forget that Class::DBI is heavily used and supported in Catalyst!

    On the other hand the days of CDBI may be ending since a replacement is being made in the form of DBIx::Class (however with an API that includes/will include the CDBI API, so you loose nothing if you have to switch).


    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      I suspect Class::DBI will be around for quite a bit longer than you think. No need to spread FUD about it's demize. There is a huge community built up around it, and lots of development still happening in the plugin space. There are still a few shortcomings in the core code, but the code is very stable and used in production all over the place. And despite the issues witnessed last month, I'm sure a new version will come out.

      On the other hand, DBIx::Class seems to still be in the experimental stages AFAIK. And the fact that it is entirely based on Multiple Inheritance magic using @ISA tricks gives me the willies... That is personal opinion, and does not necesarily mean DBIx::Class is crap, but is something to keep in mind!

        @ISA "tricks"? DBIC provides some shortcuts to save you typing over use base qw/.../; but there's absolutely no requirement to do that. Nice but optional syntactic sugar is a good thing surely, no?

        DBIx::Class also has a Class::DBI compat layer which can pass the vast majority of the Class::DBI test suite, and a fair number of its own. It's still pretty new, but well worth considering for new projects - and we tend to operate the "submit a failing test case and it'll happen" principle for feature requests. It's also going to be able to support a lot of features Class::DBI simply won't (I went about as far as I could with my work on Class::DBI::Sweet).

        If you need total stability above all else, use Class::DBI for sure - but if you're more interested in an actively developed project with an open process and a growing community, or want the greatest potential future feature set, DBIx::Class is definitely worth evaluating.

        - Matt S Trout, DBIx::Class project founder

Re: Tie::DBI vs Class::DBI
by sintadil (Pilgrim) on Aug 20, 2005 at 19:11 UTC

    I'm trying to decide between Tie::DBI and Class::DBI, and I would like to know your opinions about the relative merits of these two choices. (I'm leaning towards Tie::DBI, because it looks more straightforward, but the fact that Class::DBI appears to be far more popular makes me wonder if I'm missing something.)

    Alzabo is my O/R (object-relational) mapping of choice. It does everything I could ever use, and even has quite a bit of smarts about it. Also keep in mind that what is popular is not always right and what is right is not always popular. You might indeed decide to go with CDBI because of that very popularity (more software tends to be written to take advantage of it than Alzabo or TDBI), but I do suggest you try Alzabo.

Re: Tie::DBI vs Class::DBI
by siracusa (Friar) on Aug 21, 2005 at 02:03 UTC

    Don't forget Rose::DB::Object, which is newer than Class::DBI but older than DBIx::Class. It's also significantly faster than both of them, if that's important to you :)

    Tie::DBI, Alzabo, and Tangram offer interfaces and philosophies that are different than the modules listed above. This is a crowded category of modules. There are a lot of choices on CPAN, none of which is "right" for every situation.

Re: Tie::DBI vs Class::DBI
by fmerges (Chaplain) on Aug 20, 2005 at 23:58 UTC


    Don't know the complexity of your needs, but, it can also be that something like DBIx::Abstract is sufficient...

    If it is something more complex, or you want more abstraction from what is laying under... I would suggest you Alzabo too, or Class::DBI.

    Alzabo suits perfect if you use Mason (same developers), but not only... The thing is that you have a web interface to define your scheme, but Alzabo can also create a scheme on the tables you actually has.


    |fire| at
Re: Tie::DBI vs Class::DBI
by diotalevi (Canon) on Aug 22, 2005 at 03:09 UTC
    When I last looked, Tie::DBI had a particularly nasty implementation that was prone to blowing memory.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://485375]
Approved by neniro
Front-paged by cees
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (9)
As of 2017-02-27 19:06 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (392 votes). Check out past polls.