1. Practical uses of new T-SQL functionality in SQL Server 2012 & Windows Azure SQL Database

4. CREATE SEQUENCE [ schema_name. ] sequence_name [ AS { } ] [ START WITH ] [ INCREMENT BY ] [ MINVALUE | NO MINVALUE ] [ MAXVALUE | NO MAXVALUE ] [ CYCLE | NO CYCLE ] [ CACHE [ ] | NO CACHE ] NEXT VALUE FOR [ schema_name. ] sequence_name [ OVER ( ) ] EXEC sp_sequence_get_range …

5. Guaranteed to be globally unique Can be made sequential Caveats! Really hard to guess… (when not sequential) Use any data type for keys (for ex. strings) Can guarantee a continuous range of values (no wholes) Including ranges Serializes number generation across transactions Supports all integer types, starting from TINYINT up to DECIMAL(38, 0) Supports range reservation Caching “knob” for performance tuning Large; requires 16 bytes storage Many systems don’t natively support GUIDs Causes fragmentation Sequential generation cannot be guaranteed even with NEWSEQUENTIALID () Access to the identifier is serialized across transactions Performance issue Not native RDBMS functionality, more code Cannot guarantee a continuous range of values E.g. can “lose” values because of dirty shutdowns or rollbacks GUIDs Pros Cons Separate tableSequences

7. THROW,, ; always aborts the batch Batch aborts if not in SET XACT_ABORT ON where it Transaction-aborts Does not automatically use sys.messages is even spelled correctly! re-THROW BEGIN CATCH …; THROW; END CATCH

8. Flexible Well known Logs events without sending a message to the client Multiple behaviors, easy to get it wrong Not supported on SQL Database RAISERROR Pros Cons xp_logevent Flexible, supports the attributes you specify Transactions need to be managed so log records are not rolled back Logging table Easy to use Similar behavior to other programming languages Re-throw capabilities Less flexible than RAISERROR THROW

10. TranIdAccountIdTranDateAmount 112011-12-19120 222011-12-20500 332011-12-21430 412011-12-2695 522011-12-2750 632011-12-2825 712012-01-02250 822012-01-0325 932012-01-045000 1012012-01-0975

11. 3 trn. avg. TranIdAccountIdTranDateAmount 112011-12-19120 222011-12-20500 332011-12-21430 412011-12-2695 522011-12-2750 632011-12-2825 712012-01-02250 822012-01-0325 932012-01-045000 1012012-01-0975 120.000 310.000 350.000 341.666 191.666 56.666 108.333 100.000 1758.333 1700.000 The FRAME Window PARTITION The FRAME Window FRAME

12. BalanceTranIdAccountIdTranDateAmount 112011-12-19120 412011-12-2695 712012-01-02250 1012012-01-0975 1312012-01-16125 1612012-01-23175 222011-12-20500 522011-12-2750 822012-01-0325 1122012-01-10125 120 215 465 540 665 840 500 550 575 700 Window PARTITIONs The FRAME Window FRAME

14. Approach that is commonly used in other programming languages Follows the SQL set based paradigm Improved optimization Easy to write Following the SQL set based paradigm Not set based Only individual queries are optimized, not the operation as a whole Many lines of code  Higher risk for bugs Bad performance due to plan with N 2 complexity solution Non-trivial to write Not always the optimal solution Not all queries can be easily rewritten to leverage window functions Imperative approach Pros Cons Correlated sub queriesWindow Functions

18. SELECT... ORDER BY... OFFSET ROWS FETCH NEXT ROWS ONLY EXECUTE [WITH [,...n ]] { RESULT SETS {UNDEFINED|NONE|( )} } ::= { | AS OBJECT [.] {table_name | view_name | tvf} | AS TYPE [schema_name.]table_type_name | AS FOR XML | (…) [,...n ]}

20. Questions?