How can I force remote client applications to call my stored procedure?
I want to deny the direct execution of SQL statements from remote clients.
Can I do that?
Making the stored procedure do the entire job is it bad choice from performance perspective and security perspective
Thanks
can I do that ?
Sure. You create a user/login for the application to use and assign it to just the public role on the database. Then grant it execute permissions on the required stored procedures. The application generally doesn't need access to the underlying objects the stored procedure calls.
making the stored procedure do the entire job is it bad choice from performance perspective and security perspective
Performance will depend on the stored procedures and overall database design. There's no general reason performance couldn't be perfectly acceptable, however.
Security-wise, you only grant access to what you want the user/login to access and that's good. Again, there's no general reason security wouldn't be perfectly acceptable.
Related
At work, I have come across several SQL Server stored procedures that are only used by a single job. In that case, wouldn't it just make more sense to run the code in a job step? Is there some benefit from running statements in stored procedures?
These specific stored procedures do not require input variables, nor are they commonly used calculations; they are mostly just complex select statements. Looking for advice on best practice and performance impact.
There should be no material performance difference.
Code in a stored procedure is stored in the user database, present in backups, owned by the database owner, and can be invoked and debugged from anywhere.
Code in a job step is stored in the MSDB system database and owned by the job owner and can only be run through Agent.
I have been helping a small to medium sized business implement a new CRM using entity framework core for sql server. They are very protective over their sql database to the point where they refuse to grant permissions to most of the tables and only grant some permissions on some columns (this is how they have worked in the past, using views to do all data operations).
I have argued the case for giving entity framework permissions, but have been refused on the grounds that large sized enterprises would under no circumstances have credentials that have full access to the live database.
what are the best practices for database access when releasing to a production environment? Do major organizations normally have a username and password that has full control over both the data and also the schema for migrations, or is there a correct approach to limit the access that the ORM has ?
I agree with Dan. There's not much point in using EF if you're creating stored procedures for all CRUD operations. For any sizable system that's a lot of procedures. I rewrote some older code, moving from all stored procedures to EF Core, giving EF full read/write access. Stored procedures are easier in that you know absolutely everything going on in the database. No surprises. But a lot of code to write and maintain. EF Core lets you focus on using the data, without having to write much SQL code. The way I see it, the previous system still had complete data access. It had to or it couldn't manage the data. It was just broken up into hundreds of stored procedures instead of a single data context. In the end, I didn't see EF Core's privileges as much of an additional security risk. If the idea is that the complexity of the procedures kept it from being attacked, I think that's a weak argument. Once an attacker has system access one might presume they can figure out the rest.
An answer to this question states that "Ideally, though, you would not allow ad hoc DML against your tables, and control all DML through stored procedures."
Why is this ideal? What problem does this solve versus GRANTing SELECT, UPDATE, INSERT, DELETE to the tables which a user needs to manipulate?
Views and stored procedures are like an API. They allow you to hide the implementation, version changes, provide security and prevent unfortunate client operations like "get all fields from all invoices since the company started".
Views and stored procedures allow the DBA to modify the schema to meet performance requirements without breaking applications. The data may need to be partitioned horizontally or vertically, split across files, fields may have to be added or removed etc. Without stored procedures, these changes would require extensive application changes.
By controlling the stored procedures and views each application uses you can provide versioning of schema changes - each application will see the database API it expects.
Permissions can also be assigned on specific stored procedures, allowing you to restrict what users can do without giving them full access to a table. Eg, you could allow regular employees to change only their contact details on the employee table but allow HR to make more drastic changes.
Additionally, you can encapsulate complex data-intensive operations in a single testable procedure, instead of managing raw SQL statement strings inside a client's source code.
Stored procedure execution can also be tracked a lot easier with SQL Server Profiler or with dynamic management views. This allows a DBA to find the hotspots and culprits for possible performance degradation.
I would believe this follows the general idea that actions should have defined allowable input and return the expected output. The idea of ad-hoc changes to the data or database structure poses risk on several levels, but may be necessary based on what is required.
zerkms noted in the comments: there are no absolutes, only best practices. As a best practice, if you can correctly scope the intended outcomes and restrict users and processes to only necessary actions and permissions, you should for the safety and integrity of the system.
There are a few solid reasons for why you need to use Stored procedure
Stored procedures are compiled once and stored in executable form, so procedure calls are quick and efficient. Executable code is automatically cached and shared among users.
Stored procedure avoids SQL injection.
A set of queries in a stored procedure is executed with a single call. This minimizes the use of slow networks, reduces network traffic, and improves round-trip response time(for example in the case of bulk inserts).
I often use stored procedure for data access purpose but don't know which one is best view or SP.
Stored procedure and views are both compiled and execution plan is saved in database. So please tell me which one is best for data access purpose and why best list down the reason please.
I search google to know which one is best but got no expected answer.
I disagree with Jared Harding when it comes to stored procedures causing application updates to be more difficult. It's much easier to update a stored procedure than to update application code, which might need to be recompiled and require you to kick users out of the system to make an update. If you write all your SQL in stored procedures, you'll probably only have to update the application half as often as you otherwise would. And a stored procedure can be updated with no disruption to the users.
I strongly recommend use of stored procedures over views or SQL written within application code. With parameterized stored procedures that use dynamic SQL built as a string and called with the secure sp_executesql function, you can write a single stored procedure for selecting data that can be used across multiple applications and reports. There is virtually no need to use a view unless you really need to block permissions on underlying tables. It's much better to create your basic SELECT query inside a stored procedure and then use parameter options to change how the results are filtered. For example, each parameter can add a different line to your WHERE clause. By passing no parameters, you get back the full unfiltered recordset. As soon as you need to filter your results by a different field, you only need to add one parameter and one line of code in that procedure, and then have any application that needs to make use of it pass in the parameter. By defaulting your stored procedure parameters to null, you don't have to change any applications which are calling that stored procedure for other purposes.
Views and stored procedures serve entirely different purposes. Views are a convinient way to refer to a complex relational set (such as one that joins across many tables) as a flat table without actually forcing the data to be manifested. You use a view to clean up SQL code. Your stored procedures could call views. Views are often used for permission control. You can grant a database user access to a view without granting them access to the underlying tables. This grants the user column level permissions on the columns in the view which is a far more granular method for permission control than granting access to whole tables.
Stored procedures are used to keep often used functionality together as a unit. To be honest, SPs are falling out of favor among many programmers. While you are correct that SPs have their execution plans cached, dynamic SQL has had execution plan caching since SQL Server 2000 (I believe that's the correct version). The only speed gain you're going to get by going with SPs is by sending less data over the network, and that's going to be extremely minimal. SPs tend to make code more brittle and require changes to the DB to occur when application changes don't really warrant it. For example, if you just wanted to change the conditions for which rows you're selecting. Using SPs, you're going to have to roll changes out to the application and the database code. If you're using dynamic SQL or an ORM tool, you only need to make changes to the application which simplifies deployment. There is absolutely a time and place for SPs, but they don't need to be your only method for interacting with the database.
Also, if you're worried about performance, you can materialize views which reduces the need to repeatedly query the underlying tables. This could greatly enhance your performance if you feel the need to add the extra overhead on inserts/updates that materializing views induces.
To speed up the query you need properly defined indexes on the table. Within a stored procedure you can use paramteres, implement your own logic, however within a view you cannot
Because: Once procedure is compiled it makes its execution plan and use same for every time we call it even when we insert new data in related table as well, untill we make any change in procedure code.
View check for new updated data every time you call it.
You can do whole transaction handling etc with SP.
in my recent subject ,I have to do some queries through dynamic SQL,But I'm curious about
the efficiency in different ways:
1)combine the sql sentences in my server and then send them to the database ,do the query
2)send my variables to database and combine them in a certain procedure and finally do the query
Hope someone can help
BTW(I use .Net and Sqlserver)
Firstly, one of the main things you should do is to parameterise your SQL - whether that be by wrapping it up as a stored procedure in the DB, or by creating the SQL statement in your application code and then firing the whole thing in to the DB. This will mean:
prevention against SQL injection attacks by not directly concatenating user-entered values into a SQL statement
execution plan reuse (subsequent executions of that query, regardless of parameter values, will be able to reuse the original execution plan) (NB. this could be done if not parameterised yourself, via Forced Parameterisation)
Stored procedures do offer some extra advantages:
security ,only need to grant EXECUTE permissions to the stored procedures, you don't need to grant the user direct access to underlying db tables
maintainability, a change to a query does not involve an application code change, you can just change the sproc in the DB
network traffic, not necessarily a major point but you're sending less over the wire especially if the query is pretty large/complex
Personally, I use stored procedures most of the time. Though the times I need to build up SQL dynamically in application code, it is always parameterised.
Best is to use stored procedure and pass parameters from your application, as Stored procedures are precompiled queries and have execution plan ready which saves lot of time.
You can refer this url which has details http://mukund.wordpress.com/2005/10/14/advantages-and-disadvantages-of-stored-procedure/
Happy coding!!