MySQL Gets Perl Stored Procedures 266
ryarger writes "Woo Hoo! After a seeming eternity of wait, there is finally an implementation of stored procedures for MySQL. It uses Perl as the stored proc language, too!" Also note that this piece of work was done by OSDNs own Krow. Very cool work I must say.
Re:Not a DB guru (Score:2, Insightful)
Given that ideal: Most stored procedures are just very complex select statements anyway.
Re:Better stored proc languages... (Score:2, Insightful)
I would also like ... (Score:2, Insightful)
I agree that having a Transact-SQL equivalent will be key to consideration by serious database users, but it's just a starting point.
Re:I would also like ... (Score:4, Insightful)
I wouldn't bitch about performance too much - if that's all you want, just ditch SQL entirely and use an embedded DB like Berkeley. Truth is, features/performance is a sliding scale, not a binary option. For some applications, being able to use stored procedures in a few different languages might be very helpful. For other applications, an SQL parser itself is unacceptable overhead.
Cram your Mod points... (Score:4, Insightful)
You don't know the first damn thing about database programming, do you? The stored procedure code isn't re-parsed every time it's run. The execution plan for the query is cached and *that* is run. The performance hit would only be seen the first time the SP was run, when the recompile occurs. Having multiple SP languages would be a very good thing.
No, not really, it is that kind of attitude that got MySQL into the position it's in today, everyone acknowledges it's fast, but nobody has any respect for it as a real database.
No no no, damnit. We need to get past these shitty Procedural SQL hacks. T/SQL and PL/SQL are crap, Why do you think Oracle is integrating Java and Microsoft is integrating ActiveX into the database engine? Because trying to do high-level programming in SQL is complete shit. Why would MySQL want to integrate a legacy language like PL/SQL?
One other reason (Score:2, Insightful)
1. Most database pre-parse the stored procedures and keep the cached parsed information in memory. Really complex SQL queries can take a significant amount of time to parse, and cutting down on that overhead can be a huge win for some applications (it was for one of our queries!).
2. Stored procedures can encapsulte logic that requires multiple SQL queries into one call. This saves the network overhead of making multiple trips to the database, which can potentially be huge (and even be REALLY huge if you open up a new connection for each SQL query and then shut the connection immediately).
I don't know if the Perl procedures remain parsed, but at the very least they should be able to accomplish #2. Personally though, I'm going to wait till mySQL supports some sort of Transact SQL like stored procedures. I don't see a justifiable reason for the overhead involved in running Perl on my database. That just strikes me as a bad idea (same goes for java).
Re:I would also like ... (Score:3, Insightful)
Neither of these options are precluded by a correct abstract interface.
There's no doubt that such an abstract interface would hurt performance, but I would venture to say that you would give back much less than 1% of the stored procedure benefits by doing this. You can do a large number of JNI-Like calls in the ~8ms required to complete a network round trip. Add compilation and query optimization and you have a large number Vs. a very small number.
To be able to provide a migration path for both sers of MS SQL Server/Sybase, Oracle, and DB/2 seems compelling even though and such migration path is likely to be an 80/20 proposition.
Not a bad idea, in my view.
Re:Why not stored procs in SQL? (Score:1, Insightful)