For truly one-off things, I'd agree. But how many of these do you want to reinvent: sorting by multiple columns, grouping, aggregate functions, file locking, deleting, inserting, updating, selecting by multiple criteria, etc. etc. A six line DBD::CSV or DBD::AnyData script can accomplish all of those. And when it comes to output or integrating the handling of that table into a larger context, do you want to reinvent all of that or leverage the many DBI extension modules for those purposes?
I think it's foolhardy to say that either the database way or the non-database way is always the right way, it depends entirely on context. And as far as howitzers go, it is a matter of trading the howitzer of including modules (which may make very little difference in the long run) against the howitzer of coding all the details from file opening to parsing to sorting.
| [reply] |
i agree w/jZed's response to this, too.. For me, i basically had 3 reasons (some of the overlap w/jZed) for the DBI suggestion:
- i naturally thought DBI beacuse of how the OP worded the requirements -- it screamed RDBMS, and i strongly suspect the OP whad SQL in his mind when envisioning the requirements.
- The DBI solution could easily turn out very elegant, as opposed to a slew of (possibly tedious) loops/hashing up (though it may be a good excercise for OP)
- The scope/size of OP's problem was unclear -- it seemed like OP might have just given us a very small example, and could very well have a lot more data (and "tables"), which goes towards making the DBI solution more appealing. (and faster once it's set up, cause of indexes)
| [reply] |
