But isn't it too slow and doesn't it have too much conceptual overlap with DBI to be the first choice? | [reply] |
fenLisesi:
I always access DBD::ODBC through DBI. (I don't know how to talk to it directly.) While some claim that ODBC is "slow", I've not found it to be slow for the standard SQL statements I use.
I'm sure that it's probably significantly slower than other DBI backends for some workloads and or databases, but I haven't run across it yet.
I tend to use it for simple DDL and DML manipulations with small tables (less than 10 million rows).
...roboticus
| [reply] |
Not sure about the speed, but I don't understand your second comment. DBD::ODBC is a DBD driver meant to be used with DBI. Did you mean that Win32::ODBC has too much conceptual overlap with DBI?
| [reply] |
Sure, I understand that DBD::ODBC is a DBD driver meant to be used with DBI. That is precisely what I thought was the problem.
ODBC is a layer, is it not (I am really not an expert there), that gives you a standard way to access different kinds of database. DBI is a layer that gives you a standard way to access different kinds of database. I am sure one could generate enough material for ten threads just talking about their differences, but this is the conceptual overlap that I was talking about.
By using DBD::ODBC as your go-to guy, aren't you condemning yourself to using two abstraction layers most of the time? PostgreSQL (or another database) at the bottom, ODBC on top of that, DBI on top of that and your logic on top. Town Musicians of Bremen, where the Dog and the Cat do similar gigs. What would we lose by putting the Dog out to pasture?
There may well be problems (certain combinations of Perl, DB etc.) that are best (or only) solved by having the Dog in there, but I thought that wouldn't make the best default solution.
| [reply] |
