MySQL Forums
Forum List  »  Stored Procedures

Re: No Dynamic SQL in Function or Trigger Frustration
Posted by: Mike Jonsson
Date: March 15, 2014 02:26AM

>> 1. How difficult is it to re-write a local version of MySQL from source to actually permit this feature to function?

>Very, even if you're an accomplioshed C++ programmer.

>> To jump between C, C#, VB, PHP, Python or anything else to do this would increase runtime to anywhere in the #Nth millions of years to run til completion

>What's the point of such hyperbole? Developers implement calculations of the sort you describe every day in app languages like PHP.

PHP? Gosh, that would take 345 million years while holding a browser window open... This is a straight forward 20 degrees equation with a limited number of solutions given by constraints.

Pre-code loop is 20 While - End While
Validation of constraint ranges from 20 to 70 nested if's, whiles or for's


>> The base tables for my query applies a combination of tables. 4 to be precise, using 5 columns in each to set 20 possible values.

>> For each string of 20 I intend to account for spreads and statistical offsets between the various numbers when applied as a matrice [sic]

>SQL is set-based, so it isn't an optimal tool for large-matrix calculations like that. Are you sure you shouldn't be using something like R?

Expand on what R stands for please!?


--
The reason for using MySQL straight all along is that the results must, if established to be few enough to store in database on HDD (without reaching Petabyte limits) the results must be retained immediately.

The jumping back and forth as above is as explanation for the hassle and trillions of extra loads when opening connection, saving data, closing connection as you go from language base to language base.

An import of a textfile generated from just a tiny subset of data by LOAD DATA INTO would equally require at least 24 hours of load time just for say 360 * 10^6 records found valid.
--

I have managed to constrin datasets so far in MySQL to only make use of a limited result range. This scraps nearly 1.62*10^17 checks down to 1.3*10^12 which need to be done. (however then you miss some vital stats along the way)

My previously mentioned 312 line function to replace the lack of triggers and functions not being permitted to use dynamic SQL has now been revamped to four times as many validations on 1/3 the number of lines.

I will surely soon figure out how to reduce this even further I hope.

But as I said above, please provide a link to what you call R above.
Any information is better than no information as I see it at this point.

Options: ReplyQuote


Subject
Views
Written By
Posted
Re: No Dynamic SQL in Function or Trigger Frustration
1224
March 15, 2014 02:26AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.