Very brief background:
We are making use of CLR stored procedures to apply access control, using Active Directory, on query results to restrict what the end user can see accordingly. In a nutshell, this is done by removing rows from a datatable where the user does not satisfy the criteria for access to the result (document in this case).
This filtering was previously done on the client before displaying the results. SQL 2008 and a much more powerful server is the motivation for moving this access filtering off the client.
What I am wondering is, is there any performance benefit to be had from calling the original regular T-SQL stored procedure from the CLR stored procedure equivalent, instead of having 'inline' T-SQL passed into the comand object (which in this case is just the original T-SQL that was made a stored procedure) ? I cannot find anywhere where someone has mentioned this (in part probably because it would be very confusing as an example of CLR SPs, I guess :-) ).
It seems to me that you might, as the T-SQL stored proc has already been optimised and compiled ?
Is anyone able to confirm this for me ?
Hope I've been clear enough. Thanks very much,
Colm.
If your SQL CLR stored procedure does a specific query properly (nicely parametrized) and executes it fairly frequently, then that T-SQL query will be just run once through the whole "determine the optimal execution plan" sequence and then stored in the plan cache of your SQL Server (and not evicted from it any faster than a similar T-SQL stored procedure).
As such, it will be just as "pre-compiled" as your original T-SQL stored procedure. From that point of view, I don't see any benefit.
If you could tweak your SQL statement from within your SQL CLR procedure in such a way that it would actually not even include those rows into the result set that you'll toss out in the end anyway, then your SQL-CLR stored procedure executing a properly parametrized T-SQL query might even be a bit faster than having a standard T-SQL stored procedure return too much data from which you need to exclude some rows again.
Related
I'm declaring a cursor in a stored procedure with following;
declare cur1 cursor for select * from tmp_01;
Here, my temporary table source is tmp_01.
The source table name is dynamically generated.
I'm wondering if there is a way that I could define the same cursor with different source for each instance when the stored procedure called.
For example,
on first run,
declare cur1 cursor for select * from tmp_01;
on second run,
declare cur1 cursor for select * from tmp_02;
The main problem I'm having is, I'm experiencing some strange behavior with the cursor when called with multiple queries using mysqli_multiquery, that is not clear to me. when I run each query separately, everything works fine. I'm not sure whether it's because something like parallel query processing.
All I'm trying to achieve is, declaring a unique source name for the cursor, on each procedure call.
Can anyone please point me in a right direction to achieve this?
No, the DECLARE CURSOR statement must take a fixed SQL query as its argument, and therefore the table name must be fixed. If your table name is variable, you cannot use a cursor in a stored routine.
It's not clear from your question what purpose you have for using multiquery, or what is the "strange behavior" you have seen. I can guess that it has to do with the fact that each call to a stored procedure returns multiple result sets, so it gets confusing if you try to call multiple procedures in a multiquery. If you are looping over multiple result sets, it becomes unclear when one procedure is done with its result sets and the next procedure starts returning its result sets.
Regardless, I don't recommend using multiquery in any case. There is hardly ever a good reason to use it. There's no performance or functionality advantage of using multiquery. I recommend you just run each call individually, and do not use multiquery.
For that matter, I also avoid using MySQL stored procedures. They have poor performance and scalability, the code is harder to write than any other programming languages, there is no compiler, no debugger, no support for packages, no standard library of utility procedures, the documentation is thin, etc. I understand that in the Oracle or Microsoft SQL Server community, it is customary to write lots of stored procedures, but in MySQL, I write my application logic in a client programming language such as Java, Go, or Python.
I have a website using mySQL database and I want to do common tasks like add users, modify their info, etc. I can do it perfectly with regular queries. Im using prepared statements to increment security.
Should I use stored procedures to increment the security or the results will be the same? I though that may be using stored procedures I can restrict the direct interaction that a possible attacker could have with the real query. I'm wrong?
I guess it would depend on what language youre using. Using a prepared statement with a sql string that contains all of the sql to be executed, or using a prepared statement with a sql string that executes a stored procedure are going to be about equivalent in most languages. The language should take care of the security around the prepared statement. C# for example will validate the input, so sql injection vulnerabilities are greatly reduced unless your prepared statement is written so poorly that feeding it bad (but expected, ie, 1 vs 0) variables will dramatically change the result set. Other languages may not provide the same level of validation though, so there may be an advantage depending on exactly what your stored proc looks like.
Using a stored procedure is better for maintainability, but there are not many scenarios where its going to provide any sort of change in security level, assuming the program is properly designed to begin with. The only example i can think of off the top of my head would be a stored procedure that takes raw sql strings from user input, and then executes that sql against the db. This is actually less secure than using a prepared statement unless you went to great lengths to validate the acceptable input, in which case you better have a really good reason for using such a stored proc in the first place.
Basically, what I'm saying boils down to the fact that you're going to need to read the documentation for your language about prepared statements, and determine what vulnerabilities, if any, using prepared statements may have, and whether or not those can be eliminated in your specific scenario by switching to a prepared statement that calls out a stored procedure instead of executing a sql query directly.
The results would be the same (assuming that you set your stored procedure up right).
there appears to be a pretty good write up on it here. Though I would never suggest you try to escape user input yourself. (They mention this as option 3)
We have a large database and we do manipulations on it ever day by using the basic mysql queries.
Can anyone please tell me, what is the use of Mysql Stored Procedures?
The real use of the Stored Procedures comes into picture when have any application accessing database.
For example: Imagine that you have written all your database operations in the form of queries in your data access code.
Suppose, that you need to make any change to query , then you need to rebuild and redeploy the entire application in order see your changes.
But, if you are using stored procs and refering them in application, you can just make changes in your database with out need for redeploying the application.
So, obviously better security , maintainability and much more
Note: This is one scenario where stored procs are better than normal queries.
Usage of Stored Procs also avoids SQL Injection Attacks
In very simple words, stored procedures allow you to store your quires along with database, you can combine multiple quires in single procedure. now whenever you want to execute those quires just "CALL yourProcedure;"
Need to perform specific query daily ?
Read about MySQL events = stored procedures with scheduling capability !
https://dev.mysql.com/doc/refman/5.1/en/events.html
Sometimes an application requires quite a few SQL queries before it can do anything useful. I was wondering if there is a way to send those as a batch to the database, to avoid the overhead of going back and forth between the client and the server?
If there is no standard way to do it, I'm using the python bindings of MySQL.
PS: I know MySQL has an executemany() function, but that's only for the same query executed many times with different parameters, right?
This process works best on inserts
Make all you SQL queries into Stored Procedures. These eventually will become child stored procedures
Create Master Store procedure to run all other Stored Procedures.
Modify master Stored procedure to accept values required by child Stored Procedures
Modify master Stored procedure to accept commands using "if" statements to know which
child stored procedures to run
If you need return data from Database use 1 stored procedure at the time.
I have been following Richard Siddaway's Awesome Series on Powershell+Access2007.
Unfortunately it ends before discussing creating/running/modifying access 2007 queries in powershell. How could this be done?
The cited series of articles uses a definition of stored procedure that is problematic. It says:
An SP is a piece of code that we have
defined, and saved in the database".
While this may be correct in a metaphorical sort of way, it's incorrect for Access/Jet/ACE. There is no CODE in the objects in a Jet/ACE database that are referred to by the generic term "procedure. In Access/Jet/ACE, a "procedure" is just a stored QueryDef, as there is no procedural code allowed. I don't know if the OLEDB interface restricts it or not, but my guess is that PROCEDURE means DML query and VIEW means SELECT.
So (and I'm just guessing here -- I'm an Access developer so have no need for doing any of this externally), if you want to create/update a DML QueryDef, you'd use the PROCEDURE keyword and the relevant DML for creating/altering PROCEDUREs. Likewise, with SELECTs, you'd use VIEW (I'm assuming).