No need to use any other schema based ORM works in my opinion. It really provides very nice and logical interface between DB tables and Perl, it is easy to use and since it is using SQL, it is very flexible. I prefer to stick SQL instead of schema based ORMs.
It takes care of a lot of the tedious code you have to write to use DBI. The method names needed to access the results are easy to remember, and it delegates very sensibly common tasks, like creating HTML tables from the results, to other modules.
I am not really into ORM, I prefer to write the SQL myself, and this is the best module I've found for this. Basically its interface is what DBI's should be (which of course is easier to figure out now than when DBI was written).
DBIx::Simple is sugar spread on DBI (it should really have been named DBI::Sweet). It's usage will make you code far more readable, quicker to write, and with a lot less boilerplate code.
This is my #1 choice for database management, as using the DBI directly requires some tedious coding which is senseless to do by hand.
DBIx::Simple, even though it does provide optional query abstraction through SQL::Abstract, does not feature database abstraction. For that you should take a look at more advanced modules such as DBIx::Class and Rose::DB::Object. However, for the quick and simple case, DBIx::Simple just rocks.
it's pretty usable Module for working with databases
but need some improvement for example return usable things (eg:last inserted id) while calling crud functions like (insert,update,delete,select)
and also more sample and docs could be better
Initially, I purposely avoided using any helper or abstractor modules on top of DBI, because I wanted to see what real problems I would encounter with its use â€“ if any. After a couple of projects with it under my belt, the main problem that stuck out was that I was going crosseyed at all the (select|fetch)(all|row|col)_(array|hash)(ref)? methods in my code (some of them *additionally* modulated by passing an empty hash to indicate that I want an AoH rather than an AoA). What data structure would any piece of my code return? I could never tell at a glance, so I was fighting an increasingly uncomfortable feeling of programming by coincidence. I had lost my confidence and kept getting jarred out of the flow, so my productivity was taking a substantial hit.
So I struck out to find what DBIx::* modules from the CPAN might be applicable, and to evaluate how well theyâ€™d address this particular need of mine.
Most of the modules that made it into my first broad selection have a very different focus. Closest among the differently-focussed modules are DBIx::DWIW and DBIx::Easy, which were in the race until the penultimate round. Those mainly allow you to avoid some of the more menial SQL labouring, but they come up short in terms of options for simplified fetching of results. Since I already have a lot of SQL queries written, and because the things I ask of my databases are usually not complicated, but still non-trivial, I did not stand to gain much from the major offerings of these modules.
Thus, the last two modules standing were DBIx::ContextualFetch and DBIx::Simple. In this shootout, DBIx::ContextualFetch clearly loses. It does not address fetching results as flattened structures at all, and all of its handful of methods have quite similar names, much like in DBI. Its main aim seems to be to keep with DBI tradition. In contrast, DBIx::Simple offers methods for pulling out query results in every possible data structure you might prefer, and the methods are named distinctly and memorably, with a natural and consistent scheme for distinguishing between fetching only one row or all of them. It is exactly what I need.
Itâ€™s additionally nice for integrating SQL::Abstract, SQL::Interp, DBIx::XHTML_Table and Text::Table smoothly, without putting any pressure on the user to buy into these modules. I have found the SQL::Interp integration very natural; and while I have no need for DBIx::XHTML_Table or Text::Table right now, the integration offers a very easy growth vector. Thatâ€™s all quite cool, and reflects the same virtues as Perl itself or other great modules like the Template Toolkit. (But I avoid SQL::Abstract because of limitations in the SQL constructs it can express and because I find complex queries written in its datastructure-as-language style very hard to read.)
This is one excellent module: simple and focused on a particular purpose which it fulfills perfectly. I recommend it without any reservation.