TSQL Coding Guidelines
Upcoming SlideShare
Loading in...5
×
 

TSQL Coding Guidelines

on

  • 4,909 views

T-Sql programming guidelines, in terms of:- ...

T-Sql programming guidelines, in terms of:-

1. Commenting code
2. Code readability
3. General good practise
4. Defensive coding and error handling
5. Coding for performance and scalability

Statistics

Views

Total Views
4,909
Views on SlideShare
4,884
Embed Views
25

Actions

Likes
3
Downloads
170
Comments
2

7 Embeds 25

http://wollatondba.blogspot.com 10
https://twitter.com 6
http://www.linkedin.com 4
http://paper.li 2
http://twitter.com 1
http://wollatondba.blogspot.com.au 1
http://wollatondba.blogspot.in 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • There should be a download button above the presentation itself, other people have managed to download this.
    Are you sure you want to
    Your message goes here
    Processing…
  • Its good but how to download?
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • &lt;number&gt; <br />
  • &lt;number&gt; <br />

TSQL Coding Guidelines TSQL Coding Guidelines Presentation Transcript

  • T-SQL Coding Guidelines
  • Commenting code Code readability General best practise What Will Be Covered
  • Comments and exception handling have been purposely omitted from code fragments in the interest of brevity, such that each fragment can fit onto one slide. Disclaimer
  • Comments and exception handling have been purposely omitted from code fragments in the interest of brevity, such that each fragment can fit onto one slide. Disclaimer
  • Code Readability
  • All code should be self documenting. T-SQL code artefacts, triggers, stored procedures and functions should have a standard comment banner. Comment code at all points of interest, describe why and not what. Avoid in line comments. Comments
  •  Comment banners should include:- Author details. A brief description of what the code does. Narrative comments for all arguments. Narrative comments for return types. Change control information. An example is provided on the next slide Comment Banners
  • CREATE PROCEDURE /*===================================================================================* //* /* */ */Name : uspMyProc /* /* /* /* /* /* ( */ */ */ */ */ */ Description: Stored should procedure to demonstrate what a specimen comment banner look like. Parameters : @Parameter1 int, /* First parameter passed into procedure. */ */ */ /* --------------------------------------------------------------------------- @Parameter2 int /* Second parameter passed into procedure. ) /* /* /* /* /* /* /* /* */ */ */ */ */ */ */ */ Change History ~~~~~~~~~~~~~~ Version ------- 1.0 Author -------------------- C. J. Adkin Date -------- 09/08/11 Ticket ------ 3525 Description ------------------------------------ Initial version created. /*===================================================================================*/ AS BEGIN . . Comment Banner Example
  •  -- This is an example of an inline comment Why are these bad ? Because a careless backspace can turn a useful statement into a commented out one. But my code is always thoroughly tested NO EXCSUSE, always code defensively Use /* */ comments instead. Use Of Inline Comments
  • Use and adhere to naming conventions. Use meaningful object names. Never prefix application stored procedures with sp SQL Server will always scan through the system catalogue first, before executing such procedures Bad for performance Naming Conventions
  • Use ANSI SQL join syntax over none ANSI syntax. Be consistent when Camel case Pascal case Use of upper case Be consistent when using case:- for reserved key words indenting and stacking text. Code Readability
  • Coding for Performance
  •  Never blindly take technical hints and tips written in a blog or presentation as gospel.  Test your assumptions using “Scientific method”, i.e.:-  Use test cases which use consistent test data across all tests, production realistic data is preferable.  If the data is commercially sensitive, e.g. bank account details, keep the volume and distribution the same, obfuscate the sensitive parts out.  Only change one thing at a time, so as to be able to gauge the impact of the change accurately and know what effected the change. The “Scientific Method” Approach
  • • For performance related tests always clear the procedure and buffer cache out, so that results not skewed between tests, use the following:- are – – – CHECKPOINT DBCC FREEPROCCACHE DBCC DROPCLEANBUFFERS The “Scientific Method” Approach
  •  A term coined by Jeff Moden, a MVP and frequent poster on SQL Server Central.com . Alludes to:- Coding in procedural 3GL way instead of a set based way. Chronic performance of row by row oriented processing. Abbreviated to RBAR, pronounced Ree-bar. Avoid “Row by agonising row” Techniques
  • Code whereby result sets and table contents are processed line by line, typically using cursors. Correlated subqueries. User Defined Functions. Iterating through results sets as ADO objects in Server Integration Services looping containers. SQL Where “Row by agonising row” Takes Place
  • A simple, but contrived query written against the AdventureWorkds2008R2 database. The first query will use nested subqueries. The second will use derived tables. Sub-Query Example
  • SELECT ProductID, Quantity AdventureWorks.Production.ProductInventory PiFROM WHERE LocationID = (SELECT TOP 1 LocationID AdventureWorks.Production.Location Loc Pi.LocationID = Loc.LocationID CostRate = (SELECT MAX(CostRate) FROM WHERE AND FROM AdventureWorks.Production.Location) ) Sub-Query Example With RBAR
  • SELECT ProductID, Quantity FROM (SELECT TOP 1 LocationID AdventureWorks.Production.Location Loc CostRate = (SELECT MAX(CostRate) FROM WHERE FROM AdventureWorks.Production.Location) ) dt, AdventureWorks.Production.ProductInventory Pi Pi.LocationID = dt.LocationIDWHERE Sub-Query Example Without RBAR
  •     What is the difference between the two queries ?. Query 1, cost = 0.299164 Query 2, cost = 0.0202938 What is the crucial difference ?  Table spool operation in the first plan has been executed 1069 times.  This happens to be the number of rows in the ProductInventory table. The RBAR Versus The Non-RBAR Approach Quantified
  •  Row oriented processing may be unavoidable under certain circumstances:-  The processing of one row depends on the state of one or more previous rows in a result set.  The row processing logic involves a change to the global state of the database and therefore cannot be encapsulated in a function. In this case there are ways to use cursors in a very efficient manner  As per the next three slides.  Efficient Techniques For RBAR When It Cannot Be Avoided
  •  Elapsed time 00:22:27.892 DECLARE @MaxRownum @OrderId @i int, int, int; SET @i = 1; CREATE TABLE #OrderIds ( rownum OrderId int IDENTITY (1, 1), int ); INSERT SELECT FROM INTO #OrderIds SalesOrderID Sales.SalesOrderDetail; SELECT FROM @MaxRownum = MAX(rownum) #OrderIds; WHILE @i < BEGIN SELECT FROM WHERE @MaxRownum @OrderId = OrderId #OrderIds rownum = @i; SET @i = @i + 1; END; RBAR Without A Cursor
  • Elapsed time 00:00:03.106 DECLARE @s int; DECLARE c CURSOR FOR SELECT FROM SalesOrderID Sales.SalesOrderDetail; OPEN c; FETCH NEXT FROM c INTO @s; WHILE @@FETCH_STATUS = 0 BEGIN FETCH NEXT FROM c INTO @s; END; CLOSE c; DEALLOCATE c; RBAR With A Cursor
  • Elapsed time 00:00:01.555 DECLARE @s int; DECLARE c CURSOR FAST_FORWARD FOR SELECT FROM SalesOrderID Sales.SalesOrderDetail; OPEN c; FETCH NEXT FROM c INTO @s; WHILE @@FETCH_STATUS = 0 BEGIN FETCH NEXT FROM c INTO @s; END; CLOSE c; DEALLOCATE c; RBAR With An Optimised Cursor
  •  No T-SQL language feature is a “Panacea to all For example:- Avoid RBAR logic where possible Avoid nesting cursors But cursors do have their uses. Be aware of the FAST_FORWARD optimisation, applicable when:- The data being retrieved is not being modified The cursor is being scrolled through in a forward only direction ills”. Cursor “RBAR” Morale Of The Story
  •  When using SQL Server 2005 onwards:- Use TRY CATCH blocks. Make the event logged in CATCH block verbose enough to allow the exceptional event to be easily tracked down. NEVER use exceptions for control flow, illustrated with an upsert example in the next four slides. NEVER ‘Swallow’ exceptions, i.e. catch them and do nothing with them. Exception Handling
  • DECLARE @p int; DECLARE c CURSOR FAST_FORWARD FOR SELECT ProductID FROM Sales.SalesOrderDetail; OPEN c; FETCH NEXT FROM c INTO @p; WHILE @@FETCH_STATUS = 0 BEGIN FETCH NEXT FROM c INTO @p; /* Place the stored procedure to be tested * on the line below. */ EXEC dbo.uspUpsert_V1 @p; END; CLOSE c; DEALLOCATE c; Exceptions Used For Flow Control Test Harness
  • CREATE TABLE SalesByProduct ( ProductID int, Sold int, CONSTRAINT [PK_SalesByProduct] ( ProductID ) ON [USERDATA] ) ON [USERDATA] PRIMARY KEY CLUSTERED Exceptions Used For Flow Control ‘Upsert’ Table
  • Execution time = 00:00:51.200 CREATE PROCEDURE uspUpsert_V1 (@ProductID BEGIN SET NOCOUNT ON; int) AS BEGIN TRY INSERT INTO SalesByProduct VALUES (@ProductID, 1); END TRY BEGIN CATCH IF ERROR_NUMBER() = 2627 BEGIN UPDATE SET WHERE SalesByProduct Sold += 1 ProductID = @ProductID; END END CATCH; END; ‘Upsert’ Procedure First Attempt
  • Execution time = 00:00:20.080 CREATE PROCEDURE uspUpsert_V2 (@ProductID BEGIN SET NOCOUNT ON; int) AS UPDATE SET WHERE SalesByProduct Sold += 1 ProductID = @ProductID; IF @@ROWCOUNT = 0 BEGIN INSERT INTO SalesByProduct VALUES (@ProductID, 1); END; END; ‘Upsert’ Procedure Second Attempt
  •  With SQL Server 2008 onwards, consider using the MERGE statement for upserts, execution time = 00:00:20.904 CREATE PROCEDURE uspUpsert_V3 (@ProductID int) AS BEGIN SET NOCOUNT ON; MERGE USING AS source ON SalesByProduct AS target (SELECT @ProductID) (ProductID) (target.ProductID = source.ProductID) WHEN MATCHED THEN UPDATE SET Sold += 1 WHEN NOT MATCHED THEN INSERT (ProductID, Sold) VALUES (source.ProductID, 1); END; ‘Upsert’ Procedure Third Attempt
  • Scalar functions this function:- are another example of RBAR, consider CREATE FUNCTION RETURNS int AS BEGIN udfMinProductQty ( @ProductID int ) RETURN ( SELECT FROM WHERE MIN(OrderQty) Sales.SalesOrderDetail ProductId = @ProductID ) END; RBAR and Scalar Functions
  • Now lets call the function from an example query:- SELECT ProductId, dbo.udfMinProductQty(ProductId) FROM Production.Product Elapsed time = 00:00:00.746 RBAR and Scalar Functions: Example
  • Now doing the same thing, but valued function:- using an inline table CREATE FUNCTION tvfMinProductQty @ProductId INT ) RETURNS TABLE AS RETURN ( ( SELECT MAX(s.OrderQty) AS MinOrdQty FROM Sales.SalesOrderDetail s WHERE s.ProductId = @ProductId ) RBAR and Scalar Functions A Better Approach, Using Table Value Functions
  • Invoking the inline TVF from a query:- SELECT ProductId, (SELECT MinOrdQty FROM dbo.tvfMinProductQty(ProductId) FROM Production.Product ORDER BY ProductId ) MinOrdQty Elapsed time 00:00:00.330 RBAR and Scalar Functions A Better Approach, Using Table Value Functions
  • Developing applications that use database perform well depends on good:- Schema design Compiled statement plan reuse. Connection management. and Minimizing the number of network round trips between the database and the tier above. Compiled Plan Reuse
  •  Parameterise your queries in order to minimize compiling. BUT, watch out for “Parameter sniffing”. At runtime the database engine will sniff the values of the parameters a query is compiled with and create a plan accordingly. Unfortunate when the values cause plans with table scans, when the ‘Popular’ values lead to plans with index seeks. Writing Plan Reuse Friendly Code
  •  Use the RECOMPILE hint to force the creation of a new plan. Use the optimise for hint in order for a plan to be created for ‘Popular’ values you specify. Use the OPTIMISE FOR UNKNOWN hint, to cause a “General purpose” plan to be created. Copy parameters passed into a stored procedure to local variables and use those in your query. Parameter Sniffing
  •  For OLTP style applications:-       Transactions will be short Number of statements will be finite SQL will only affect a few rows for each execution. The SQL will be simple. Plans will be skewed towards using index seeks over table scans. Recompiles could double+ query execution time.  Therefore recompiles are undesirable for OLTP applications. When (Re)Compiles Are To Be Avoided
  •  For OLAP style applications:- Complex queries that may involve aggregation and analytic SQL. Queries may change constantly due to the use of reporting and BI tools. May involve WHERE clauses with potentially lots of combinations of parameters. Foregoing a recompile via OPTION(RECOMPILE) may be worth taking a hit on for the benefit of a significant reduction in total execution time.  This is the exception to the rule. When Taking The Hit Of A (Re)Compile Is Worthwhile
  • Be careful when using table variables. Statistics cannot be gathered on these The optimizer will assume they only contain one row unless the statement is recompiled This can lead to unexpected execution plans. Table variables will always inhibit parallelism in execution plans. Table Variables
  • This applies to conditions in WHERE clauses. If a WHERE clause condition can use an index, this is said to be ‘Sargable’ A searchable argument As a general rule of thumb the use of a function on a column will suppress index usage. i.e. WHERE ufn(MyColumn1) = <somevalue> Sargability
  •  Constructs that will always force a serial plan:- All T-SQL user defined functions. All CLR user defined functions with data access. Built in function including: @@TRANCOUNT, ERROR_NUMBER() and OBJECT_ID(). Dynamic cursors. Be Aware Of Constructs That Create Serial Regions In Execution Plans
  •  Constructs that will always force a serial region within a plan:-          Table value functions TOP Recursive queries Multi consumer spool Sequence functions System table scans “Backwards” scans Sequence functions Global scalar aggregate Be Aware Of Constructs That Create Serial Regions In Execution Plans
  • Advise From The SQL Server Optimizer Development Team  Craig Freedman, a former optimizer developer has some good words of advice in his “Understanding Query Processing and Query Plan in SQL Server” slide deck.  The points on the next three slides ( quoted verbatim ) come from slide 40.
  • Watch Out For Errors In Cardinality Estimates  Watch out for errors in cardinality estimates  Errors propagate upwards; look for the root cause  Make sure statistics are up to date and accurate  Avoid excessively complex predicates  Use computed columns for overly complex expressions
  • General Tips  Use set based queries; (almost always) avoid cursors  Avoid joining columns with mismatched data types  Avoid unnecessary outer joins, cross applies, complex sub-queries, dynamic index seeks, …  Avoid dynamic SQL (but beware that sometimes dynamic SQL does yield a better plan)  Consider creating constraints (but remember that there is a cost to maintain constraints)  If possible, use inline TVFs NOT multi-statement TVFs  Use SET STATISTICS IO ON to watch out for large numbers of physical I/Os  Use indexes to workaround locking, concurrency, and deadlock issues
  • OLTP and DW Tips  OLTP tips:  Avoid memory consuming or blocking iterators  Use seeks not scans  DW tips:  Use parallel plans  Watch out for skew in parallel plans  Avoid order preserving exchanges
  • • OLTP tips: – Avoid memory consuming or blocking iterators – Use seeks not scans • DW tips: – Use parallel plans – Watch out for skew in parallel plans – Avoid order preserving exchanges
  • Miscellaneous Best Practise
  • Leverage functionality already reinvent it, this will lead to:- More robust code Less development effort Potentially faster code Code with better readability Easier to maintain code in SQL Server, never Avoid Reinventing The Wheel
  •  This is furnishing the code with a facility to allow its execution to be traced. Write to a tracking table And / or use xp_logevent to write to event log DO NOT make the code a “Black box” which has to be dissected statement by statement in production if it starts to fail. Code Instrumentation
  •  Make stored procedures and functions relatively single minded in what they do. Stored procedures and functions with lots of arguments are a “Code smell” of code that:- Is difficult to unit test with a high degree of confidence. Does not lend itself to code reuse. Smacks of poor design. Favour Strong Functional Independence For Code Artefacts
  •   Understand and use the full power of T-SQL. Most people know how to UNION results sets together, but do not know about INTERSECT and EXCEPT.  Also a lot of development effort can be saved by using T-SQL’s analytics extensions where appropriate:-      RANK() DENSE_RANK() NTILE() ROW_NUMBER() LEAD() and LAG() (introduced in Denali) Leverage The Full Power Of Transact SQL
  • Bad Practices To Avoid
  •  An ‘Ordinal’ in the context of the ORDER BY clause is when numbers are used to represent column positions.  If the new columns are added or their order changed in the SELECT, this query will return different results, potentially breaking the application using it. SELECT TOP 5 [SalesOrderNumber] ,[OrderDate] ,[DueDate] ,[ShipDate] ,[Status] FROM [AdventureWorks].[Sales].[SalesOrderHeader] ORDER BY 2 DESC Avoid Ordering By Ordinals
  • SELECT * retrieves all columns from a table bad for performance if only a subset of these is required. Using columns by their names explicitly leads to improved code readability. Code is easier to maintain, as it enables the “Developer” to see in situ what columns a query is using. Avoid SELECT *
  •  A scenario that actually happened:- A row is inserted into the customer table Customer table has a primary key based on an identity column @@IDENTITY is used to obtain the key value of the customer row inserted for the creation of an order row with a foreign key linking back to customer. The identity value obtained is nothing like the one for the inserted row – why ? Robust Code and @@IDENTITY
  • @@IDENTITY obtains the latest identity value irrespective of the session it came from. In the example the replication merge agent inserted row in the customer table just before @@IDENTITY was used. The solution: always use SCOPE_IDENTITY() instead of @@IDENTITY. a @@IDENTITY Is Dangerous !!!
  • SQL Tri State Logic  SQL has tri-state logic: TRUE, FALSE and NULL.  SQL data types cannot be compared to NULL using conventional comparison operators:  <some value> <> NULL  <some value> > NULL  <some value> < NULL  <some value> = NULL  Always use IS NULL, IS NOT NULL, ISNULL and COALESCE to handle NULLs correctly.
  • NULL Always Propagate In Expressions  Expressions that includes NULL will always evaluate to NULL, e.g.:  SELECT 1 + NULL  SELECT 1 – NULL  SELECT 1 * NULL  SELECT 1 / NULL  SELECT @MyString + NULL  If this is not the behaviour you want, code around this using ISNULL or COALESCE.
  • Use Of The NOLOCK Hint  Historically SQL Server has always used locking to enforce Isolation levels, however:  SQL Server ( 2005 onwards ) facilitates non blocking versions of the read committed and snapshot isolations levels through multi version concurrency control (MVCC).  SQL Server 2014 which uses MVCC for its in memory OLTP engine.  All Azure Database databases use the MVCC version of read committed snapshot isolation.
  • Use Of The NOLOCK Hint  Objects can be scanned in two ways:  Allocation order, always applied to heaps, can apply to indexes.  Logical order, indexes are traversed in logical leaf node order.  Any queries against indexed tables (clustered or non- clustered) using NOLOCK that are perform allocation- ordered scans will be exposed to reading the same data twice if another session causes the page to split and the data to move during this process.
  • Use Of The NOLOCK Hint  If a session uses a NOLOCK hint on a heap / clustered index, its reads would ignore any locks taken out on pages/rows by in-flight transactions and subsequently be able read uncommitted ( dirty ) data, if that row is in the process of being changed by another session.  If the in-flight transaction rolls back, this leaves the session in a state whereby it has read dirty data, i.e. data that has been modified outside of a safe transactional context.  Thanks to Mark Broadbent (@retracement) for checking this and the last two slides.
  • Transaction Rollback Behaviour CREATE TABLE Test (col1 INT) BEGIN TRANSACTION INSERT INTO Test VALUES (1); UPDATE Test SET col1 = col1 + 1 WHERE 1/0 > 1; COMMIT; SELECT col1 FROM Test -- ** 1 ** row is returned CREATE TABLE Test (col1 INT) SET XACT_ABORT ON BEGIN TRANSACTION INSERT INTO Test VALUES (1); UPDATE Test SET col1 = col1 + 1 WHERE 1/0 > 1; COMMIT; SELECT col1 FROM Test -- ** No rows ** are returned. For SQL Server to automatically rollback an entire transaction when a statement raises a run time error SET XACT_ABORT must be set to ON.
  • Contact Details chris1adkin@yahoo.co.uk ChrisAdkin8 http://uk.linkedin.com/in/wollatondba