Interface wise, i would not be terribly worried about this. I mean, the DBM modules have been tieing hashes to "databases" all along. I can see feeling un-easy tho.
My major concern would be speed as compared to SQL. If each UPDATE, SELECT, INSERT or DELETE is a single statement handle, there could be some major amounts of waste. If, there is a single statement handle, it maybe a bit better. I see no fundumental problem with <code lang="perl">Tie</code>'ing, but i would suggest testing some of the following under Benchmark
- hash slices , do they work ? (if you tie,you make the next deveoper not need to understand it is a database)
- speed of insert versus SQL insert
- use of key with mis-matched datatype (does it die ? can you supply a handler ?)
these are just a few, but , i have never used the module, and all of these maybe coverd by a quick look through the perldoc, or some quick code trolling. I find i ask better (read as simpler) questions when i have yet to look at the code.
i had a memory leak once, and it ruined my favorite shirt. | [reply] |
I just downloaded the Tie::DBI module to take a look before commenting, and it looks pretty cool.
It probably works fine, although Lincoln does mention a fairly significant speed penalty over plain DBI.
Personally I'd use the regular DBI syntax, mostly for maintainability, and because it clearly exposes what SQL statements are going to get executed - if you ever need to find out why a certain part of your app is performing slowly then this is really a necessity. Another thing that I don't think it does is JOIN queries, and that's another thing that you're likely going to need if you go beyond a very simple app.
Just my $0.02, of course :-)
Michael
| [reply] |