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
Related
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)
I'm working on an order system that can have anywhere from 1 to 200+ orders in it. Right now we have a loop that loops through each order and inserts it into the database. Would it make sense to use SqlBulkCopy? Would using it degrade performance on small orders? Are there any other techniques to speed up inserts?
Thanks!
Basically there are several things you can do.
using SqlBulkCopy.WriteToServer which doesn't work great together with EF, however there are several attempts to create extensions
using a stored procedure which will take one big record and split it according to some logic
using table-typed stored procedure parameters and do one call to the stored procedure (and several insert ... select inside the stored procedure)
Overall, I prefer third option.
Check this question Entity Framework Stored Procedure Table Value Parameter
I am trying to work with EF, for the first time ever. I'm not sure I fully understand EF yet.
I already have a database with data in it, so I've generated my models from DB.
Our current setup runs EVERYTHING through stored procedures, even selects.
However, unless I'm mistaking, the models select directly into the tables, when I have generated them.
Can I change this behaviour, so it calls the select procedure instead?
No - at least with EF4. I can't speak for EF5
You can use stored procedures to insert and update, but those stored procedures must have all the parameters EF expects, so you're probably going to have to wrap your existing procedures in new procedures.
For select, you can use a FunctionImport and ExecuteFunction to populate an Entity.
I'm trying to program a database, and I'm using a mix of parameterized queries and stored procedures. Mostly I'm using pqs inside sprocs. I'm doing each correctly, and getting the proper results. However, each time I log out of the mysql server and back in, the sprocs are still there, but it acts like I never programmed any pqs. It only works if I do the pqs all over again from scratch. I haven't seen anything either in lectures or online about pqs being temporary, so is there something I'm doing wrong? Thank you.
You have an apples-and-asterisks category confusion.
Apples: Stored procedures are persistent server-side objects with names in the name space of a particular MySQL database. Just like table definitions, views, and table contents, they are part of your database.
Asterisks: Parameterized queries (prepared statements) are client-side objects that are created underneath a particular connection to the DBMS. They're objects in the class hierarchy of whatever connection library (in whatever language) you happen to be using. Their lifetimes cannot exceed the lifetime of the connection.
If your app happens to be using more than one connection (for example, if it's multithreaded) you need to create your parameterized query for the particular connection you're using.
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.