Re: Perl and Oracle

Mladen Gogala <gogala_at_sbcglobal.net> 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