SQL – Stored Procedure Vs Ad-Hoc (In-Line)

This would be a valuable decision making between the stored procedures and doing SQL (Ad-Hoc (In-Line) SQL) inside the coding before developing the back end of a database application. 

At that time, you need to decide the best approach to accomplish your tasks (insert, update, delete, view and other SQL statements) by using stored procedures or Ad-Hoc (In-Line) SQL. As performance wise both stored procedure or Ad-Hoc (In-Line) SQL, both stored in cache and hardly any difference in new SQL versions. Before make the right decision, we can see the advantages and disadvantages of stored procedures as shown below:

Advantages of Stored procedures:

1. They are more easily available for code reviewed. After creating once, you can call them n-number of times from the various sources and no need to write you SQL query again and again. This is the biggest relief for a developer.
2. Stored procedures are stored in a pre-complied form and stores in our database. That is once a Stored procedure is executed, the compiled code is used in subsequent calls whereas Ad-Hoc (In-Line) SQL codes are compiled each and every time whenever you called in application and they stay in your application code. You can tested your stored procedures easily due to less coupled.
3. By using Stored procedures we can separate all the queries from the Business logic code and more easily tuned them whenever we want them. Stored procedures prevents SQL Injection Errors and provide the security to our database.
4. Performance is generally better, from the point of view of network traffic - if you have a cursor, or similar, then there aren't multiple trips to the database but this is not applicable for Ad-Hoc (In-Line) SQL.
5. By using them, we can protect access to the data more easily, remove direct access to the tables, enforce security through the procs - this also allows you to find relatively quickly any code that updates a table.
6. If there are other services involved (such as Reporting services), you may find it easier to store all of your logic in a stored procedure, rather than in code, and having to duplicate it.
7. Developers and database designers can work concurrently using stored procedures. While a programmer writes business logic, another one can create stored procedures at the same time. This is not possible with Ad-Hoc (In-Line) SQL.
8. One more thing is if we can wrong execute store procedure the transaction may rollback but Ad-Hoc (In-Line) SQL can't for many update statement.
9. Stored procedures keep coding and debugging simpler by dividing the work up into layers.

Disadvantages of Stored procedures

1. The real problem with stored procedures is that many programmers that use them are inclined to use procedural programming techniques like cursors, loops, recursion which defeats the purpose of a database engine optimized for set based queries.
2. The only down side of stored procedures are maintenance and redeployment. It's a little annoying to make an update and redeploy it from development to the production platform.

Now, we will discuss them which is better based on the below points-

Performance : Use inline SQL for CRUD operations and there is no need to write a stored procedure if the select statement is based on a single table then Ad-Hoc (In-Line) SQL will perform this task in more better way but remember security should be part of your design phase. Stored Procedures, especially in MS SQL Server have a major performance benefit.  One of the reason to use Stored Procedure instead of inline SQL in the program is because of CPU consumption and even though the SQL itself is simple, each time you executed it inline, the SQL engine needs to compile it (check statistics, prepare plan, etc.) before it can be run. Once the inline SQL has been parameterized into a Stored Procedure, the plan will be prepared and thus, will not need to be compiled again when it is executed the hundreds/thousands of times / minute. Stored procedures support to use much less network traffic and again improve scalability.

Security: If you used a secured model of using Stored Procedures and only given access to execute stored procedures to the user then you’re adding a new layer of security which might (or might not) save you from that attack. It is resolved by using parameterized SQL which eliminate the SQL injection possibility. Allowing ad-hoc SQL implies that the calling user context (whether integrated or standard security model is used) has access to the tables themselves. Such a model puts all the security control in the hands of the client when it probably ought to live in multiple layers. (Obviously, not all applications need to be particularly secure.) Restricting a user to the stored procedure interfaces not only abstracts the data, it protects the tables from a malicious user.

Maintainability: You can modify a SQL statement without having to compile and redeploy the application. If the application does not use stored procedures exclusively, there will be SQL fragments in several places in the code and every single fragment must be inspected in detail and followed from its origin to the construction of a complete SQL statement and its handoff to the database - to verify that the application is safe from SQL injection. This is a great deal more work. By using stored procedures and views, you abstract the code from the underlying database structure, and enable yourself to make changes to optimize it.

With simple inline queries, dynamic SQL is very easy to create. If your applications have complex queries, then the lack of a visual SQL creation tool makes them very lumbering and error prone.

Development speed: You can modify a SQL statement without having to compile and redeploy the application. Developers and database designers can work concurrently using stored procedures. While a programmer writes business logic, another one can create stored procedures at the same time. This is not possible with Ad-Hoc (In-Line) SQL.

Conclusion

So it is always better to stick to Ad-Hoc (In-Line) SQL for small requirement and for a medium, secured and complex logic depend on stored procedures. Stored procedures have been limited to batch processes where the ability to process large volumes of data as quickly as possible is essential and they are aligned much more closely to the tenets of design-by-contract, test-driven development, verifiable inputs/outputs, and code readability. Stored procedures are cached and reused a lot more efficiently than dynamic SQL. Ad-hoc SQL provides a lot of run-time flexibility. Disallowing direct table access ensures that correctly written stored procedures can validate correct visibility to underlying data.

There is a very simple fundamental fact that most seem to neglect, T-SQL is not a programming language, it’s a relational language driven by an engine which is very dynamic and complex, that requires maintenance, optimization and monitoring in order to ensure scalability and performance. By taking the code out of the database, you are leaving DBA handicapped from controlling the data flow and ensuring uptime. And while this will work in a lot of environments this is not an enterprise approach, and designs such these require complete redesign.

Learn more on another feature of SQL as:

1. SQL - Stored Procedure
2. SQL - Create Stored Procedure
3. SQL - Execute Stored Procedure
4. SQL - Alter Stored Procedure
5. SQL - Views
6. SQL – Stored Procedure Vs Ad-Hoc (In-Line)
7. SQL - Merge Statement
8. SQL - Functions
9. SQL - Cursors

SQL- Difference between Temp Table and Table Variable

What's the difference between a temp table and table variable in SQL Server?

In the real practice, it depends on the situations where we need to choose the current approach to complete the task by using of a table variable or a temp table. I usually use what's more convenient at that time and experiment a bit.

We can easily differentiate them based on the following contents –

Contents	Table Variable	Temporary Table
Storage Location	Table variable is NOT necessarily memory resident. Under memory pressure, the pages belonging to a table variable can be pushed out to tempdb.	Stored in the tempdb.
Logical Location	It acts like a DDL operation whenever we create a table variable and metadata of the table variable always stored in system catalog. User-defined data types and XML collections must be in current database to use for table variables.	Temporary tables always stored in the tempdb. User-defined data types and XML collections must be in tempdb to use for #temp tables.
Scope	Table variables have a limited scope. They are accessed within the same batch and scope in which they are declared.	Temp tables can be accessed within child batches (nested triggers, procedure, exec calls).
Lifetime	Table variable are created implicitly when a batch containing a DECLARE @.. TABLE statement. They are dropped implicitly at the end of the batch execution. We cannot use the table variable before the DECLARE statement.	Temp tables are created explicitly when the TSQL CREATE TABLE statement is encountered and can be dropped explicitly with DROP TABLE or will be dropped implicitly when the batch ends.
Transactions and Locking	Table variables don’t participate in transactions or locking. They are carried out as system transactions.  This can be a useful feature, e.g. during a transaction certain activities can be logged in a table variable - if the transaction is rolled back then the table variable is available for inspection.	Temp tables operations would be carried out as part of the user transactions. A NOLOCK hint or READ UNCOMMITTED isolation level can of course be specified explicitly when working with temp tables as well.
Indexes	For versions prior to SQL Server 2014 indexes can only be created implicitly on table variables as a side effect of adding a unique constraint or primary key. Additionally table variables do not support INCLUDE columns, filtered indexes or partitioning.	Temporary tables comply to the same rules as permanent tables when it comes down to indexing. We need to create indexes on the temp table after fully populated the data. Indexes on temporary tables do not come at a higher priority than indexes on permanent tables
Other Functional Differences	Queries that insert into (or otherwise modify) table variables cannot have a parallel plan. Table variables can be used inside scalar or multi-statement table UDFs. Table variables cannot have named constraints. Table variables cannot be SELECT-ed INTO, ALTER-ed, TRUNCATE-d or be the target of DBCC commands such as DBCC CHECKIDENT or of SET IDENTITY INSERT. Table variables do not support table hints such as WITH (FORCESCAN). CHECK constraints on table variables are not considered by the optimizer for simplification, implied predicates or contradiction detection.	Queries that insert into (or otherwise modify) temp tables are not restricted in a parallel plan. Temp tables cannot be used inside a function. Temp tables have named constraints. Temp tables can be SELECT-ed INTO, ALTER-ed, TRUNCATE-d or be the target of DBCC commands such as DBCC CHECKIDENT or of SET IDENTITY INSERT. Temp tables supports table hints such as WITH (FORCESCAN). CHECK constraints on Temp tables are not considered by the optimizer for simplification, implied predicates or contradiction detection.
Statistics	No statistics is maintained on table variable which means that any changes in data impacting table variable will not cause recompilation of queries accessing table variable.	Statistics is maintained on temp tables.

Also please keep in mind, that with CTE there is a third option towards the same goal.

To know more on the different kinds of the tables in SQL Servers at

1. SQL – Wide Tables
2. SQL - Table Variables
3. SQL - Temp Table (Local & Global Temp Tables)
4. SQL - Common Table Expression
5. SQL - Difference between Table Variable and Common Type Expression
6. SQL - Difference between Temp Table and CTE
7. SQL - Difference between Temp Table and Table Variable

SQL - Temp Table (Local & Global Temp Tables)

Temporary table is also known as temp table. This is another most usable feature of the SQL Server. Temp tables are used to store temporary result set which is defined within the execution scope of a single SQL statement such as SELECT, INSERT, UPDATE, DELETE, or CREATE VIEW. 
Temp tables have the same feature as any normal data table. We can create indexes on the temp table but it depends on the requirements.

Whenever we create a temporary table, it goes to Temporary folder of tempdb database. Based on the behavior and scope of requirement, SQL server provides two types of temp tables as given below - 

1. Local Temp Table , 
2. Global Temp Table

Local Temp Tables – They are easily accessible for single user. This is the most usable in SQL server and works only in the current connection of the user. They automatically deleted from the session whenever user disconnects from instances. We can create them by starting with hash (#) sign as given below -

1. We can create them as we create permanent data tables in the database before use them and
2. We can create them by using into temp table name from the permanent table or views in the select statements. They get the same data structure from the select data columns which is very useful to avoid data conflict.

----- syntax to create temp table create table #TempEmp ( EmpId Int, EmpName Varchar(25), EmpAge int, EmpDept varchar(6) ) ----- how to insert data into temp table Insert into #TempEmp  values (1,'ABC',21,'D001'), (2,'DEF',22,'D011'), (3,'GHI',23,'D021'), (4,'JKL',24,'D031') ----- get result from the temp table select EmpId, EmpName, EmpAge, EmpDept From #TempEmp EmpId EmpName EmpAge EmpDept 1 ABC 21 D001 2 DEF 22 D011 3 GHI 23 D021 4 JKL 24 D031 ----- get filtered result into another temp table select EmpId,EmpName, EmpAge,EmpDept into #Empbelow22 From #TempEmp where EmpAge>22 ----- pull the data from select EmpId, EmpName, EmpAge, EmpDept from #Empbelow22 EmpId EmpName EmpAge EmpDept 1 ABC 21 D001 2 DEF 22 D011 ----- drop temp tables drop table #Empbelow22, #TempEmp

Global Temp Tables –They are easily accessible for multiple users. The scope of Global temporary table is the same for the entire user for a particular connection. They automatically deleted whenever all users sessions are disconnected. We can create them by starting with double hash (##) sign. We cannot set revoke and grant permissions to the global temp table because it’s always accessible to all users.

----- syntax to create Global temp table create table ##TempEmp ( EmpId Int, EmpName Varchar(25), EmpAge int, EmpDept varchar(6) ) ----- how to insert data into Global temp table Insert into ##TempEmp  values (1,'ABC',21,'D001'), (2,'DEF',22,'D011'), (3,'GHI',23,'D021'), (4,'JKL',24,'D031') ----- get result from the Global temp table select EmpId, EmpName, EmpAge, EmpDept From ##TempEmp EmpId EmpName EmpAge EmpDept 1 ABC 21 D001 2 DEF 22 D011 3 GHI 23 D021 4 JKL 24 D031

When can we use of temp tables –

There are lots of scenarios, where we can easily use of the temp table to increase the performances and solve the problems such as –

• In the stored procedure, wherever we require a large number of row manipulations. 
• They could be the replacement of the cursor in the query to store the result set data into a temp table, then we can manipulate the data from there. 
• They are the best option to do complex join operations.
• We can use of n-numbers of temp tables to do more complex data manipulation and call them in the entire single session.

Point to remember: To avoid additional overhead and performance issues, drop the temp tables after use of the temp table because Temporary table stored on tempdb of SQL Server which is a separate database.
To know more on the different kinds of the tables in SQL Servers at

1. SQL – Wide Tables
2. SQL - Table Variables
3. SQL - Temp Table (Local & Global Temp Tables)
4. SQL - Common Table Expression
5. SQL - Difference between Table Variable and Common Type Expression
6. SQL - Difference between Temp Table and CTE
7. SQL - Difference between Temp Table and Table Variable