Thoughts On Unix ODBC Implementations? 7
scenic asks: "I was wondering what people thought about the available ODBC implementations that are available for Unix. I've been looking at ways to simplify database access in my applications on Linux and Solaris without having to use API's which are specific to a particular DB (or platform, ideally). Does anyone have suggestions or comments on the ODBC software that is available for Linux or any Unix flavor? What about advantages and disadvantages of specific ODBC packages?"
How about using JDBC in Java? (Score:2)
You could even use this solution within a C or C++ application, you can use JNI to make calls into the Java code and get results back.
Re:Port to Perl (Score:1)
as for presenting data to the web, you can use the Tango product for Linux, it does ODBC and has the PSQL data engine buit in to it, your choice of either CGI or Apache plug-in.
Re:Port to Perl (Score:1)
I've had a brief look at one of their scripts - it was the first time I've seen the parallel option used in a query and also the first time I'd seen a subquery as part of the from statement.
Sure, they probably could have used Pro*C, but I doubt the execution time would be much different - the slowness is in the retrieval from the database and transmission across the network. The power of string manipulation in perl makes the coding so much quicker and easier.
I've used perl accessing Sybase to populate tables from log files and my bottleneck was the fact I was doing row at a time inserts. It would have run just as slowly if I'd used E*SQL.
If I was choosing a database interface based on platform independence I'd look to java and then perl or PHP. Java has the added bonus of being able to run within the database for some databases (no more PL/SQL?).
For a web based app the startup time of your script is likely to be the slow point. Plus if you are using a web hosting service you might not be able to upload a compiled C program (you are probably also forced to use mySQL, and would therefore use PHP.
At the end of the day its all horses for courses.
Port to Perl (Score:2)
Not only that, but the Perl DBI drivers are written mostly in C, and interface directly to the underlying driver, rather than go through another layer like ODBC (unless of course you use DBD::ODBC or DBD::ADO). This means that any database bound app (one that is limited in speed by the underlying database) is going to run at a very similar speed to your C application.
Its just a thought. Try it, you might like it.
OpenLink (Score:2)
unixODBC (Score:1)
Re:Port to Perl (Score:2)
my $db = new dbd.odbc->("", "", "");
(or whatever the method is, I can never remember these things), and the relevant call to SQLConnect() in ODBC?
I suggest that the extra layer of ODBC API pales into insignificance compared to that bloat.
To take an example: write a program with a subroutine that is empty apart one for() loop counting 0->a big number. Do this in both C and perl. The C one wins hands down by a factor of about 10.
Perl really is not the language of choice for speed freaks. If you're controlling and optimizing, of course, then you're aware that most performance is required when you're pulling back a large resultset, rather than the stop/start of individual queries. And I'd still bet that the differences in performance in the middle of a 'select * from ABigTable;' will be best in C with native API, followed closely by ODBC, followed a mile behind by perl.
Of course, it's at that point you ask *why* you want to retrieve zillions of rows - most probably not for a web-DB application, at least.
~Tim
--