Skip to main content

Stored Procedures vs. User Defined Functions in Microsoft SQL Server

                 SQL Server user-defined functions and stored procedures offer similar functionality. Both allow you to create bundles of SQL statements that are stored on the server for future use. This offers you a tremendous efficiency benefit, as you can save programming time by:
  • Reusing code from one program to another, cutting down on program development time.
  • Hiding the SQL details, allowing database developers to worry about SQL and application developers to deal only in higher-level languages
  • Centralize maintenance, allowing you to make business logic changes in a single place that automatically affect all dependent applications
          At first glance, functions and stored procedures seem identical. However, there are several subtle, yet important differences between the two:
  • Stored procedures are called independently, using the EXEC command, while functions are called from within another SQL statement.
  • Stored procedure allow you to enhance application security by granting users and applications permission to use stored procedures, rather than permission to access the underlying tables. Stored procedures provide the ability to restrict user actions at a much more granular level than standard SQL Server permissions. For example, if you have an inventory table that cashiers must update each time an item is sold (to decrement the inventory for that item by 1 unit), you can grant cashiers permission to use a decrement_item stored procedure, rather than allowing them to make arbitrary changes to the inventory table.
  • Functions must always return a value (either a scalar value or a table). Stored procedures may return a scalar value, a table value or nothing at all.
Overall, stored procedures are one of the greatest treasures available to SQL Server developers. I use them heavily in my databases and encourage you to do the same. The efficiency and security benefits you’ll reap are well worth the upfront investment in time.
Labels:

Comments

Post a Comment

Popular posts from this blog

How to Prevent Users to Press F5 key (Refresh button)

Some times we want to prevent user to Press F5 key to prevent Page Refresh. You can use the below script. Paste this code in the Head Section of your Page. <script language=javascript> document.onkeydown = function(){ if(window.event && window.event .keyCode == 116){ window.event.keyCode = 505; // Capture and remap F5 } if(window.event && window.event .keyCode == 505){ // New action for F5 return false; // Must return false }} </script>
7 comments
Read more

Access Different interface method with same Name implemented in a class

We use interface and multiple interface inherit it into class, then we implement the methods of interface as it is necessary but what will happen if two interface have the same mentods with same signature and inherited in the same class? Now questions arises from here are : Q1) Both the methods will be implementable which is with the same name and signature? Q2) If methods are implementable then how it is possible? Q3) If it is possible then can we access both the methods? Q3) If it is possible then what is the way to access these methods publically? The answer of all the above question is below: 1) Yes both the methods with same name and signature is implementable. 2) we have to implement interface explicitely preceding with iterface name. 3) Yes it is possible to access the methods. 4) Yes we can
Post a Comment
Read more

Should have on tips of our lips.........ACID PROPERTIES

Introduction    When ever we process any DML statements transactions are implicitly called. Ie. when ever no begin  transaction statement insert ,delete, update statements will have transaction statements around them implicitly. ACID concept is one of the oldest and important properties of the Database. It sets forward four goals that every database management system must strive to achieve: atomicity, consistency, isolation and durability. No database that fails to meet any of these four goals can be considered reliable. Atomicity Atomicity states that database modifications must follow an "all or nothing" rule. Each transaction is said to be "atomic." If one part of the transaction fails, the entire transaction fails. It is critical that the database management system maintain the atomic nature of transactions in spite of any DBMS, operating system or hardware failure. Consistency Consistency states that only valid data will be written to the database. If,...
2 comments
Read more