Re: Perl and Oracle
- From: xhoster@xxxxxxxxx
- Date: 11 Apr 2006 15:28:14 GMT
Mladen Gogala <gogala@xxxxxxxxxxxxx> wrote:
On Mon, 10 Apr 2006 17:00:01 +0000, xhoster wrote:
Perl cannot be used to load large files into
the database or download large query results to the file system.
Strangely enough, I've used it for both of those things. Loading files
with Perl isn't as fast as doing it with sqlldr, but then again why
would you expect it to be? If you want to use sqlldr, use sqlldr. You
can even use both, having the ctl point to a fifo for the input data
and having Perl write to that fifo.
You don't have to do that. You can write to a flat file and then create
an external table.
Sure, if you have access to OS storage on the DB server, and the DBA has
specifically configured it so that you can do that, and don't mind having a
gigantic file hanging around. sqlldr just works.
No fifology necessary.
It isn't necessary with sqlldr either. It is just a nicety that lets
you stream data from Perl into Oracle without having to write very
large temporary files on the client.
DBD::Oracle is a mere toy which works best with tables like SCOTT.EMP.
It was once stated here that Tim Bunce, the author of Perl is more
inclined to develop things for open source databases lie Postgres or
MySQL then to fix the driver for Oracle. I happen to believe that is
the case, despite the vigorous denial.
What was vigourously denied? Tim Bunce being the author of Perl?
Or something else?
Xho
I believe that Tim favors open source databases and that DBI supports
features of PgSQL and MySQL while it doesn't support the same features
of Oracle.
Which features are those? DBD::Pg seems to support array inserts the same
way DBD::Oracle (and AFAICT, DBD::mysql) does.
In other words, Tim is biased.
You are just talking out of your ass.
<snip>
I am not blind to Perl's faults either. But that doesn't mean I'll pull
fictitious ones out of my ass.
DBI is very far from being perfect. Array
calls do not work work with Oracle because of the DBI semantics which
require status for each row, while Oracle returns a status per operation.
If an operation includes 1000 rows, you'll get a single status back. DML
either succeeded or failed. You don't get status for each row.
That is the only thing preventing you from making robust and working array
insert for DBD::Oracle? That seems easy enough to circumvent.
That was
created for other databases and that is my argument for Tim's bias.
Tim is biased because he designed a general interface to be general,
rather than taylored to one specific product?
Tim
doesn't want to allow the call to return a single status, in which case
it could be possible to support array interface for Oracle. DBD::Oracle
also doesn't support threads, which is today a cardinal sin.
What do you mean by this? I use DBD::Oracle in threads with minimal
problems. The main limitations I find are in Perl's threading model itself,
not with DBD::Oracle support of it.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
.
- Follow-Ups:
- Re: Perl and Oracle
- From: Mladen Gogala
- Re: Perl and Oracle
- References:
- Perl and Oracle
- From: Matthias Hoys
- Re: Perl and Oracle
- From: Mladen Gogala
- Re: Perl and Oracle
- From: xhoster
- Re: Perl and Oracle
- From: Mladen Gogala
- Perl and Oracle
- Prev by Date: How to get a cursor from a dynamic query within a procedure?
- Next by Date: Re: Perl and Oracle
- Previous by thread: Re: Perl and Oracle
- Next by thread: Re: Perl and Oracle
- Index(es):
Relevant Pages
|
