I agree wholeheartedly that the pl/sql code will (native compiled or not)
will be much faster than the C++ code. I fully agree with you and have seen
the same type of nonsense. It usually stems from wanting to use a BSO
(bright shiny object eg name a new technology) or not wanting to take the
time to learn the proper way the tool already has to do it. (the
testosterone> brains syndome. "real programers write it from scratch")
Jim
--
Replace part of the email address: kennedy-down_with_spammers_at_attbi.com
with family. Remove the negative part, keep the minus sign. You can figure
it out.
"Paul Brewer" <paul_at_paul.brewers.org.uk> wrote in message
news:3ef0d837_1_at_mk-nntp-1.news.uk.worldonline.com...
> "Jim Kennedy" <kennedy-down_with_spammers_at_attbi.com> wrote in message
> news:MI2Ia.21436$vq.2953_at_sccrnsc04...
> >
> >
> > Actually, in 9i you can compile the pl/sql into native C code.
> > Jim
> >
> Jim,
>
> Agreed. But even without that I bet my PL/SQL routine will outperform his
> C++ by a factor of 10. And it will handle the exceptions better. In any
case
> (and sorry if this offends some), quite frankly I don't give a damn
whether
> we can compile to native or not, since 99.9% of the work we do is
> inserting/updating/deleting rows of data in the database, rather than
being
> computationally intensive.
>
> And anyway, if OP wants only to <quote> "synchronize" between two
different
> database schemas (different structurally but semantically equivalent so
that
> a mapping can be defined) <end quote>, Oracle has provided most of it
> already in the box. Fast snapshots + triggers + transformations may well
be
> the best solution here.
>
> And lastly, please accept my apologies for being irritable. Some idiots
> produced just such a system in a project I've been working with for the
last
> year and a half at work. Some joker decided that the best way to replicate
> between two Oracle 8.1.7.4 databases was to produce a VB interface to
encode
> a 'send' message in XML, and another to decode said XML into a set of
> inserts/updates in the target database.
> This is *not* a public schema; it is internal; proprietary; one-to-one.
> It could have been made to work with a few man-days effort. Instead it has
> taken hundreds of thousands of pounds to get it limping along; which it
now
> is.
> So, was the lesson learned?
> Apparently not; the next time the same question was posed, the same
solution
> was chosen.
>
> Bitter? Moi?
>
> Regards,
> Paul
>
>
>
Received on Wed Jun 18 2003 - 16:52:27 CDT
