in reply to Re: plsql vs. perl vs. neither and API's (code)
in thread plsql vs. perl vs. neither and API's (code)

Using DBI you have access to full SQL dialect of your database engine, and flexibility of perl. Don't do object if they will slow processing down, you do not have to. I suggest then to take plain old shared libraries to access database.
Try solve 80% cases of data access in your shared code, and for 20% high performance use custom SQL. I guess Knuth said that root of all software evil is optimalization too soon -- so don't do that if you are strong enough to resist...
I know it's hard not to optimize - because it is more fun, I am struggling with it too... ;)
About MySQL: there are many threads all over Net that MySQL can be faster because does not have support for transaction. From your description I am guessing you need trasaction? For this many rows, ORACLE will be safer bet, IMHO.
I am working on such an API right now, but sorry it is not ready yet...:(

pmas
To make errors is human. But to make million errors per second, you need a computer.

  • Comment on (pmas) Re: plsql vs. perl vs. neither and API's (code)