Re: Data Migration Perl style vs. SQL style....

I tend to agree with voyager and your coworkers on this one: if the job is as big as it sounds, use SQL to do the job. As soon as you start using tools external to the DBMS to start manipulating large sets of data, the speed at which the manipulation occurs is greatly decreased. While I find that DBI is pretty quick and flexible, it can never match the speed at which you can run SQL at the server console (well, at least not that I've seen!)

It certainly is nice to use/want to use perl for the manipulation, but most DBMSes that I've seen these days have some pretty decent functions for manipulating and transforming data.

Just my two bits. Hope it is some use.
MrCromeDome

Comment on Re: Data Migration Perl style vs. SQL style....

Replies are listed 'Best First'.
Re: Re: Data Migration Perl style vs. SQL style.... by mr.dunstan (Monk) on Jun 21, 2001 at 23:54 UTC
Thanks to everyone. I am basically doing this in Oracle only, I am just a little afraid that in the worst case scenario I might have to do some synchronization between all the tables instead of a one-time migration... but I think the answer is to only use SQL (takes less time to code) and shoot for a single cutover, the way super confident programmers (not necessarily me) should! I am also chomping at the bit to use XML and Perl on something, but you guys have shown me the light. Thanks again. mr.dunstan	[reply]

Replies are listed 'Best First'.

Re: Re: Data Migration Perl style vs. SQL style....
by mr.dunstan (Monk) on Jun 21, 2001 at 23:54 UTC

Thanks to everyone.

but I think the answer is to only use SQL (takes less time to code) and shoot for a single cutover

[reply]