Using Python for processing of large datasets (convincing managment)

[Cameron Laird]

In article <7xznx2j1qp.fsf at ruckus.brouhaha.com>,
Paul Rubin  <phr-n2002b at NOSPAMnightsong.com> wrote:
			.
			.
			.
>Actually, SQL tends to be awful slow too.  Recent Oracle versions let
>you write stored procedures in Java, which are orders of magnitude
>faster than PL/SQL procedures.  MySQL also has some alternate language
>interfaces for stored procedures now but I'm not up on them.

I'm *not* ready to ratify these propositions.

SQL's a special-purpose language--there's no question about
that.  To call it slow ... well, I just don't find it suf-
ficiently comparable to general-purpose languages for that
to be meaningful to me.  What I do know is that it's very
typical for beginners in SQL to do simple-minded accesses,
then sort-and-calculate in a host (client-side) language,
without realizing that they might get ORDERS of magnitude
better performance by having SQL do the calculations on the
server side.

It's also possible to push calculations to the server side
and degrade performance.  I'm simply urging Mr. Jensen to
follow through on his inclination to look to SQL improvements
as an early step in performance improvement.

We don't know yet, do we, what RDBMS he uses?  Yes, the 
vendors certainly do attempt product differentiation by the
extension languages they offer for stored procedures,
server-side functions, and other goodies.
-- 

Cameron Laird <Cameron at Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html