How to Write a Better T-SQL Code

Here are some basic guidelines that are good to consider when writing T-SQL (Transact SQL). These tips and hints are aimed for the beginner-level T-SQL developers.

Always Use a Schema for the Programmable Objects

For example, instead of writing BillOfMaterial you should have dbo .BillOfMaterial in a query.

Having SELECT col1,col2,… FROM BillOfMaterial makes the query uncertain for the database engine so it has to make additional checking. If for example there is another schema customized , then the selection of table/view BillOfMaterial can be from that schema space if it exists under, even though the developer wanted it to be from dbo . That produces an incorrect result in that case. The right table/view choice made from the database engine depends on the schema of the object from which the query is executed in.

This is working well until SQL 2012, i.e. the dbo (default schema) will be considered. However in later versions like SQL 2017 if the table exists under another schema then it might not be taken the desired table and schema. So use instead SELECT col1,col2,… FROM dbo .BillOfMaterial.

See more on this link .

Readability of Code Write Clear Code

Readability of code is important for writing nice code.

Example:

declare @businessentitycontainerid int -- not so good DECLARE @BusinessEntityContainerId INT; -- good DECLARE @Business_Entity_Container_Id INT; -- good DECLARE @BEC_Id INT; -- good

To have even better code you can use semicolons “ ; ” to end the statements. It helps the query optimizer handle the queries better.

You can also use indention for increased code readability.

Using square brackets ( [ ] ) for the objects make your code better also. It is very good for the Names that are system-like in T-SQL (e.g. Order, Type, Name, Description, …).

Use, for example, this free online formatter or plugin for SSMS http://poorsql.com/ to increase the readability of your code, if you don’t have a similar tool already.

Describe your Code

This is nice to have in the head part of the programmable objects. You write a few sentences to describe the functionality of the code that follows. You can also write the updates related to some requested tasks/issues.

Then you write comments at places within the code.

Over-commenting is not good as well as Non-commenting. Keeping moderate-by-volume commenting is best. Commenting should be smart-made, i.e. to explain something specific of the code-fragment.

The code should be self-descriptive as much as possible. That means, for example, if you need a variable to keep the Assortment ID you name it self-descriptive like

DECLARE @assortment_id INT;

but not like

DECLARE @id INT;

because further in the code someone couldn’t make a good tracking of the variable @id as it represented the Assortment ID value while overviewing.

You practice the same for the other temporary objects and variables used in the code.

Next code-fragment of a programmable object is a good example of a well described one. With minimum commenting, the code is explained well enough. First, the names of the CTEs (ValidPrices, TransferPrices) are self-describing and additionally, the short comments make it well-described and easy to understand. The code is written with an indentionand together with some aliases, it looks even better.

... ;WITH ValidPrices AS ( /*IPLs only this is client specific description*/ SELECT i.ItemID, i.[Number], [ip].[Value] [IPL SEK], [ip].ValidFrom FROM #tmpInternalPrice [ip] /*Very limited number of records from InternalPrice*/ JOIN [dbo].[CatalogDetails] cd ON cd.[ID] = [ip].CatalogDetailsID JOIN [dbo].[Item] i ON i.ItemID = cd.ItemId JOIN [dbo].[BusinessEntity] be ON be.[ID] = [ip].BusinessEntityID AND be.BusinessEntityContainerId = 2 WHERE [ip].CurrencyNumCode = '752' -- Filter out prices with SEK currency only AND [ip].BusinessEntityID = @Be_id_PC_CP -- PC level AND [ip].PriceTypeID = 3 --Valid prices ), TransferPrices AS ( SELECT i.ItemID, i.[Number], [ip].[Value] [Transfer price], [ip].ValidFrom, ISNULL(ip.ModifiedDate,[ip].[CreatedDate]) [CreatedDate] FROM #tmpInternalPrice [ip] JOIN [dbo].[CatalogDetails] cd ON cd.[ID] = [ip].CatalogDetailsID JOIN [dbo].[Item] i ON i.ItemID = cd.ItemId JOIN [dbo].[BusinessEntity] be ON be.[ID] = [ip].BusinessEntityID AND be.BusinessEntityContainerId = 2 WHERE [ip].BusinessEntityID = @be_id AND [ip].PriceTypeID = 4 /*Transfer prices only*/ ) ...

Please know that over-commenting can make the code less-readable to someone, and it could instead have a negative effect of a hard-to-read code.

Some DOs and DONTs DOs: Always use SET NOCOUNT ON ; in Stored procedures and Triggers. Try to use TRY-CATCH blocks for the UPDATE/INSERT/DELETE operations. Catching the errors and/or saving them down into a table is helping you/someone else to perform a better analysis of future potential errors generated by the code. Use the ( NOLOCK ) hint for the reporting/reading purposes only. This hint is used for ignoring locking on tables. Use EXISTS(…) instead of IN (…). IN is faulty when dealing with NULLs in the subset. Use TOP(…) together with ORDER BY . You’ll always know which rows are affected by TOP. DONTs: Never UPDATE/DELETE from tables with the (NOLOCK) hint . It can produce an undesired state. Do not use the * operator in yourSELECTstatements. Instead, use column names. For example, if the table/view columns change in future it could not work well within your code-fragment. Try to avoid SET options in the programmable code as