in reply to DBI sanity check

It's not clear from your description exactly what role Perl needs to play in your problem. Are you using it to generate the output of your report, or are you looking at Perl purely as a tool to make the join?

Assuming that the end-result of the join query needs to be available to Perl, a couple of possibilities spring to mind.

The first, although it doesn't meet your requirement that another database not be used, is that you use a SQLite database (created and accessed using DBD::SQLite) to create a temporary store for the source data from your report. This would leave you with a single SQLite file in your filesystem which you could discard when your reporting process had completed, then regenerate the next day. You get the benefit of a (more or less) SQL-92 compliant RDBMS, without any of the headache of management.
SQLite is fast, even with large datasets - it's limitations are mostly when supporting multi-user environments, which shouldn't be an issue for offline reporting.

The second (non-Perl) option would be that you explore making the Oracle database visible from Firebird, or vice-versa, using whatever remote datasource tools are available. I don't know Firebird, but I'm certain Oracle has tools to enable you to connect to and use other databases in Oracle queries. Other, more Oracle-literate Monks may have suggestions here.

Replies are listed 'Best First'.
Re^2: DBI sanity check
by mring (Initiate) on Nov 10, 2005 at 22:41 UTC
    Terce,

    Thanks for the reply. To clairify, I've already writen a few reporting scripts based on DBI and GD::Graph, I will be modifying them for this task, so yes the end-result needs to be perl accesable.

    I've read about SQLite in sysadmin journal, it sounds cool, but I'm going to try the perl methods posted here first.