In this post, I am doing a basic performance test between SELECT INTO and INSERT INTO SELECT option of SQL Server.

Database Developers are using these options very frequently for copying data between the tables. But SELECT INTO is little faster than INSERT INTO SELECT option.

Note: I am testing using a very small number of sample records. If you are testing with a huge number of records, you may find a big difference in the performance.

Please check the below examples:

Set Statistics:

SET STATISTICS IO ON
SET STATISTICS TIME ON

Create sample tables:

CREATE TABLE tbl_MyData (ID INT, Name VARCHAR(10))
CREATE TABLE tbl_Mytable (ID INT, Name VARCHAR(10))

INSERT INTO tbl_MyData VALUES (1,'dbrnd')
GO 1000000

Perform INSERT INTO SELECT:

INSERT INTO  tbl_Mytable 
SELECT ID, Name 
FROM tbl_MyData

Execution time:

SQL Server Execution Times:
CPU time = 16 ms,  elapsed time = 37 ms.

Perform SELECT INTO:

SELECT ID, Name 
INTO tbl_MyTable2
FROM tbl_MyData

Execution time:

SQL Server Execution Times:
CPU time = 16 ms,  elapsed time = 21 ms.

In this post, I am sharing an interesting fact on the disk usage by extra tabs and spaces of SQL Server object’s definition.

Many of you don’t know that extra spaces and tabs are occupying the disk in SQL Server. People are creating their own coding standard and giving a huge number of extra spaces in the object definition.

Nowadays, the disk is not that much costlier so few extra KBs/MBs we can afford. But I saw few servers, where companies are creating a separate database for each client and one database contained thousands of stored procedures.

So I would suggest, please follow the best practices in your coding life.
From tomorrow, I am going to share few articles on SQL Server Coding Standard and best practices.

Here, I created two stored procedures where one has extra tabs and other has normal spaces. You can easily get the size difference between these two stored procedures.

Create sample Stored Procedure with extra Tabs and Spaces:

CREATE PROCEDURE usp_ABC
AS
BEGIN
	DECLARE						@Name					VARCHAR(20)
	DECLARE						@Add					VARCHAR(100)	
END

Create sample Stored Procedure without extra Tabs and Spaces:

CREATE PROCEDURE usp_XYZ
AS
BEGIN
	DECLARE	@Name VARCHAR(20)
	DECLARE @Add VARCHAR(100)	
END

Compare the size of above SPs:

SELECT 
	[p].[name]
	,size = DATALENGTH([asm].[definition]) 
FROM sys.all_sql_modules AS asm
INNER JOIN sys.procedures AS p
ON [asm].[object_id] = [p].[object_id]
WHERE [p].[name] IN ('usp_ABC','usp_XYZ')

Result:

name          size
-----------  ---------
usp_ABC	      230
usp_XYZ       198

In this post, I am sharing a script to perform PINTABLE and UNPINTABLE in SQL Server.

Using PINTABLE, we can keep data in the data cache of SQL Server which boosts the speed of query execution.

Once you PINTABLE in the data cache, it doesn’t load the whole table but it keeps only required a portion of the table.

If you have enough size of the data cache, you can try this option for a frequently used table.

SQL Server Interview: How internally it executes a SQL Statement?

PINTABLE:

DECLARE @DBID INT, @TableID INT 
SET @DBID = DB_ID('DatabaseName') 
SET @TableID = OBJECT_ID('DatabaseName.SchemaName.TableName') 
DBCC PINTABLE (@DBID, @TableID)

UNPINTABLE:

DECLARE @DBID INT, @TableID INT 
SET @DBID = DB_ID('DatabaseName') 
SET @TableID = OBJECT_ID('DatabaseName.SchemaName.TableName') 
DBCC UNPINTABLE (@DBID, @TableID)

I didn’t explore few features of SQL Server 2014. Recently, I got to know that in SQL Server 2014 we can create indexes on Table Variable.

If you look into the differences between Temp Table and Table Variable, always you can find one difference like we can’t create an index on Table Variable and we can create an index on the Temp Table.

SQL Server: Difference between Temporary Table and Table Variable

In this post, I am sharing few examples of Table variable with Indexes.
Please check the below samples:

Define Table variable with Primary key and Unique key:

DECLARE @dbrnd TABLE
(
	ID INT PRIMARY KEY
	,Name NVARCHAR(10) UNIQUE
)

Define Table variable with Non-Clustered index:

DECLARE @dbrnd TABLE
(
	ID INT PRIMARY KEY
	,Name NVARCHAR(20)
	,INDEX idx_dbrnd_Name NONCLUSTERED (Name)
)

Prepared by Bihag Thaker

The stored procedure must ensure its atomicity, i.e. it either executes all statements or none. Client code (caller of a stored procedure) expects it to be this way.

It does not know how many statements are actually executed and may not implement any transaction support. In case of failure, the stored procedure must properly roll back all changes.

Before rolling back a transaction, it should check the value of @@TRANCOUNT

IF @@TRANCOUNT > 1
ROLLBACK TRANSACTION

SQL Server 2005 and later versions should use BEGIN TRY…END TRY, BEGIN CATCH…END CATCH syntax for exception handling in stored procedures.

The stored procedure should not hide/suppress errors. In cases when business functionality requires a client code to call several stored procedures/queries in a row and considers the action as an atomic action, client code must be implementing transaction support, which normally relies on the fact that an exception is raised if stored procedure fails.

If stored procedure hides an error, client transaction support will not work.

To follow this standard, throw an exception with RAISERROR() function in BEGIN CATCH…END CATCH block, pass the error details to the application and let the application handle the error. Pass the Error Number with a @ErrorNumber output parameter.

Following should be the general logic for implementing transaction along with proper exception handling:

BEGIN TRY
	BEGIN TRANSACTION
		--DML Statements go here within transaction.
	COMMIT TRANSACTION
	RETURN 0
END TRY
BEGIN CATCH
	DECLARE @ErrorNumber INT
	DECLARE @ErrorMessage NVARCHAR(4000);
	DECLARE @ErrorSeverity INT;
	DECLARE @ErrorState INT;
SELECT
	@ErrorNumber = ERROR_NUMBER(),
	@ErrorMessage = ERROR_MESSAGE(),
	@ErrorSeverity = ERROR_SEVERITY(),
	@ErrorState = ERROR_STATE();
	IF @@TRANCOUNT > 0	
		ROLLBACK TRANSACTION
	RAISERROR(@ErrorMessage,@ErrorSeverity,@ErrorState)
	RETURN 1
END CATCH

Prepared by Bihag Thaker

Prefix the User Defined Function Name with ‘trg_’.

Try to include only letters in identifiers by using Pascal Casing and avoid the use of special characters in identifiers. Underscore (_) character may be used for element separation in an identifier.

Here element means Application Prefix, type of Operation, Table Name or Entity Name etc. However, word separation in single element should be achieved with PascalCasing only.

Use proper, meaningful and self-explanatory identifiers for user-defined functions. Following naming convention should be used for trigger:

‘trg_’ + + ‘_’ + + ‘_’ +

Here, is the name of the table on which the trigger is defined. is the type of trigger. It can be either ‘AFTER’ or ‘INSTEADOF’. is the underscore (_) separated list of operations for which trigger is defined. It can be INSERT, DELETE or UPDATE.

Some of the examples are:

trg_tblOrders_After_DELETE
trg_tblOrders_After_INSERT_UPDATE

If there is some alternative solution to using triggers then avoid creating frequent triggers on the table as they degrade the performance of the DML statements.

Check if the same functionality can be achieved using the constraints as constraints are faster than triggers. Only use triggers for complex business logic whose implementation is not possible by constraints.

If the trigger is specified for INSERT, UPDATE or DELETE, do not use OUTPUT clause in their respective DML statements that fire the trigger.

Sample Trigger Code Snippet:

CREATE TRIGGER trg_TableName_AFTER_INSERT_UPDATE
ON [dbo].[tblCustomers]
AFTER INSERT,UPDATE
AS
/*
	**********************Creation Details**********************
	Stored Procedure Name : trg_TableName_AFTER_INSERT_UPDATE
	Purpose : Implements Business logic on INSERT and UPDATE
	Author : Author Name
	Created On : 2017/01/01
	-------------------------------------------------------------
	*****************************Revision Details*****************************
	Project/
	Revision No. Changed On  Changed By  Change Description
	------------ ----------  ----------  ------------------
	1234         2018/02/10   Mr. ABC    Business Logic Changed.
*/
BEGIN
	--Body of Trigger follows
END

Prepared by Bihag Thaker

Prefix the User Defined Function Name with ‘udf_’.

Try to include only letters in identifiers by using Pascal Casing and avoid the use of special characters in identifiers. Underscore (_) character may be used for element separation in an identifier.

Here element means Application Prefix, type of Operation, Table Name or Entity Name etc. However, word separation in single element should be achieved with PascalCasing only.

Use proper, meaningful and self-explanatory identifiers for user defined functions. Following naming convention should be used for stored functions:

‘udf_’ + + ‘_’ + +

Here, part can be optional. can be a verb like ‘Get’, ‘Check’, ‘Validate’ or ‘Return’ and so on. Some of the examples are:

udf_Person_ValidateEmailAddress()
udf_HR_CalculateNetSalary()

Use schemas to separate different sets of user defined functions across multiple applications when possible. For example, if schema Person is used instead of prefix ‘Person_’ and schema HR is used instead of prefix ‘HR_’, then above user defined functions should be as follows:

[Person].[udf_ValidateEmailAddress]()
[HR].[udf_CalculateNetSalary]()

Do not create Scalar-Valued Function extensively. Avoid use of Scalar-Valued Functions in queries as much as possible because they degrade the performance of the queries.

Do not create Scalar-Valued Function just for the purpose of code reusability. If same functionality can be achieved with some inline calculation, then avoid functions. Code Reusability should not come at application’s performance cost.

Do not create Multiline Table-Valued Function as they tend to degrade the performance of the queries. If the same functionality can be achieved with Inline Table-valued Function, then avoid using Multiline Table-valued Function.

While creating stored procedures, specify the name of the schema explicitly within which the stored procedure is to be created even if it is dbo.

Following is the sample template of User Defined Function. It has been provided here only to have a basic idea of coding structure and standards that a stored procedure should follow:

CREATE FUNCTION [dbo].[udf_FunctionName]
(
	@Param1 INT
	,@Param2 INT
	,@Param3 VARCHAR(50)
) RETURNS BIT AS
/*
	**********************Creation Details**********************
	Stored Procedure Name : udf_FunctionName
	Purpose : Calculates and returns the value.
	Author : Author Name
	Created On : 2017/01/01
	*****************************Revision Details*****************************
	Project/
	Revision No. Changed On  Changed By  Change Description
	------------ ----------  ----------  ------------------
	1234         2018/01/01   Mr. ABC    Changed the calculation part.
	1235         2018/02/08   Mr. XYZ    Revert the previous change.
*/
BEGIN
	--Function Body goes here.
	 RETURN (0)
END

Prepared by Bihag Thaker

Prefix the Stored Procedure Name with ‘usp_’.

Try to include only letters in identifiers by using Pascal Casing and avoid the use of special characters in identifiers. Underscore (_) character may be used for element separation in an identifier.

Here element means Application Prefix, type of Operation, Table Name or Entity Name etc. However, word separation in single element should be achieved with PascalCasing only.

Use proper, meaningful and self-explanatory identifiers for stored procedures. Stored procedures are generally used for different actions like INSERT, UPDATE, DELETE and SELECT operations.

Following naming convention should be used for stored procedures:
‘usp_’ + + ‘_’ + + /

Here, part can be optional. can be a verb like ‘Add’, ‘Insert’, ‘Update’, ‘Change’, ‘Set’, ‘Delete’, ‘Remove’, ‘Select’ and ‘Get’ and so on. Some of the examples are:

usp_Sales_GetOrderDetails
usp_Sales_InsertOrderDetails
usp_Sales_UpdateOrderDetails
usp_Sales_DeleteOrderDetails

Use schemas to separate different sets of stored procedures across multiple applications when possible. For example, if schema Sales is used instead of ‘Sales_’ as Application Prefix, then above Stored Procedures should be as follows:

[Sales].[usp_ GetOrderDetails]
[Sales].[usp_ InsertOrderDetails]
[Sales].[usp_ UpdateOrderDetails]
[Sales].[usp_ DeleteOrderDetails]

Create stored procedures and try to implement functionalities through stored procedures wherever possible rather than using ad-hoc queries from the application.

While creating stored procedures, specify the name of the schema explicitly within which the stored procedure is to be created even if it is dbo.

Return the success or failure status from the stored procedure with the use of RETURN statement. Value 1 should be used for success and 0 for failure.

If a stored procedure is required to return some value, do not use RETURN statement. The RETURN statement is not intended for this purpose. Consider using OUTPUT parameters as required in stored procedures and pass output values from OUTPUT parameters to the application.

Use @ErrorCode OUTPUT parameter to communicate with the application any error occurred in the stored procedure.

When possible, consider single stored procedure call which returns multiple result sets to the application rather than calling stored procedure multiple times for each different result set. This reduces round trips to the database server and improves the application response time.

Do not write very lengthy stored procedures. Try to keep them as short as possible.

If business logic which needs to be implemented within a stored procedure is very lengthy, then try to break the business logic into different modules and implement each different module in its separate stored procedure and call those sub-stored procedures in the main stored procedure.

Use SET NOCOUNT ON at the beginning of the stored procedures whenever possible. This can improve the performance of the queries.

Consider declaring variables at the top of stored procedures.

Do not use temporary tables and table variables frequently. When possible, see if the same functionality can be achieved by using Table Expressions like derived tables and Common Table Expressions.

Avoid creating frequent temporary tables in IF conditions within the stored procedure.

Whenever intermediate result set needs to be stored within a stored procedure, consider implementing temporary table approach and table variable approach. Compare the results between two approaches and choose the one which is efficient.

Always use transactions in the stored procedures when multiple DML statements are performed within a unit of work.

Keep transactions as short as possible to reduce locking issues.

Do not use WITH RECOMPILE option with the stored procedures.

Following is the sample template of a stored procedure. It has been provided here only to have a basic idea of coding structure and standards that a stored procedure should follow:

CREATE PROCEDURE [dbo].[usp_StoredProcedureName]
(
	@Parameter1 INT
	,@Parameter2 VARCHAR(50)
	,@ReturnValue1 INT OUTPUT
	,@ErrorCode INT = 0 OUTPUT
) AS
/*
	**********************Creation Details**********************
	Stored Procedure Name : [dbo].[usp_StoredProcedureName]
	Purpose : Insert a new record in TableName
	Author : Author Name
	Created On : 2017/01/01
	*****************************Revision Details*****************************
	Project/
	Revision No. Changed On  Changed By  Change Description
	------------ ----------  ----------  ------------------
	1234	     2018/01/10   Mr. ABC     New column 'NewColumnName' added.
	1235         2018/03/16   Mr. XYZ     Column 'ColumnName' deleted.
*/

BEGIN
	SET NOCOUNT ON
	BEGIN TRY
		BEGIN TRANSACTION
			--INSERT statement and other logic go here.
		COMMIT TRANSACTION
		RETURN 0
	END TRY
	BEGIN CATCH
		IF @@TRANCOUNT > 0
		ROLLBACK TRANSACTION
		RETURN 1
	END CATCH
END

Prepared by Bihag Thaker

Prefix the View Name with ‘vw_’

Try to include only letters in identifiers by using Pascal Casing and avoid the use of special characters in identifiers. Underscore (_) character may be used for element separation in an identifier.

Here element means Application Prefix, Group Name, Table Name or Entity Name etc. However, word separation in single element should be achieved with PascalCasing only.

Use proper, meaningful and self-explanatory identifiers for Views. Views are used for SELECT operations.

Following naming convention should be used for view: ‘vw_’ + + ‘_’ + + / Here, part can be optional. can generally a verb like ‘Get’ or ‘Select’ and so on. can be optional additional description. Some of the examples are:

vw_Sales_GetOrderDetailsForToday
vw_Sales_GetOrderDetailsTotalByCustomerID

Use schemas to separate different sets Views across multiple applications when possible. For example, if schema Sales is used instead of ‘Sales_’ as Application Prefix, then above Views should be as follows:

[Sales].[vw_ GetOrderDetailsForToday] 
[Sales].[vw_ GetOrderDetailsTotalByCustomerID]

When queries are frequently executed which require complex joins and calculations, then you should implement them in view. Consider creating views when same complex queries are executed from the different part of applications.

Whenever possible, create views that are schema bound.

Following is the sample template of a stored procedure. It has been provided here only to have a basic idea of coding structure and standards that a stored procedure should follow:

CREATE VIEW [dbo].[vw_ViewName]
AS
/*
**********************Creation Details**********************
View Name : [dbo].[vw_ViewName]
Purpose : Get all Items along with totals.
Author : Author Name
Created On : 2017/01/01
*****************************Revision Details*****************************
Project/
Revision No. Changed On Changed By Change Description
------------ ---------- ---------- ------------------
1234         2017/08/08 Mr. ABC    Two Columns Column1 and Column2 added.
1235         2018/01/13 Mr. XYZ    Caculation added.
*/

--SELECT Query goes here

Prepared by Bihag Thaker

Data integrity is an important aspect of any database. Data integrity is implemented by using constraints.

Use constraints wisely as per the requirement and nature of the application. Constraints enforce data integrity rules but using lot of constraints may realise overhead when performing DML operations on data.

So, use them as per the requirement of the application. Generally, you should use constraints to enforce the data integrity. Following are some of the guidelines which should be followed:

Creating a clustered primary key constraint is generally the best practice. You should have one primary key constraint preferably clustered on every table in your database.

To maintain data integrity, use unique constraints when a column is not expected to hold duplicate values in any case. For example, a unique constraint should be defined on Social Security Number.

Apply referential integrity with foreign key constraints whenever possible to establish relationships between primary table and foreign table to maintain data integrity.

Always, try to apply NOT NULL constraints on columns wherever possible and keep minimum columns nullable as possible. This disallows columns to have null values and simplifies the queries and other DML operations.

When it is required for a column to allow NULL values, try to define a default value by creating a default constraint on that column.

When a column is expected to hold a specific domain of values of either a set of predefined values or a range of values, then apply check constraints to maintain the data integrity on such columns.