Slides from a one hour webinar on Karen Lopez's favorite features from database designer's point of view. Topics include Always Encrypted, Data Masking, Row Level Security, Foreign Keys, JSON and more. Notice an error? Let me know. I welcome this sort of feedback.

1. Karen’s Favourite* Features of
SQL Server 2016
…from a database designer’s Point of view
Karen Lopez, InfoAdvisors

3. Karen Lopez
Karen has 20+ years of data and information architecture
experience on large, multi-project programs.
She is a frequent speaker on data modeling, data-driven
methodologies and pattern data models.
She wants you to love your data.

4. A Little About InfoAdvisors…
#TeamData
Data Management
Project Management
Business Analysis
Training
Analysts Services
Consulting
www.datamodel.com

5. “Every design decision comes
down to cost, benefit and risk.”
- Karen Lopez

6. Prelaunch Countdown
Some of these slides come from a deck
co-developed for a precon on DB
Design – with Thomas LaRock
www.thomaslarock.com @sqlrockstar

7. Launch

8. What is a DBA?
Development DBA
Database Engineer
Database Designer
Operational DBA
NoSQL DBA

9. Security

10. SQL 2005
gave us
cell-level
encryption
SQL 2008
gave us
TDE
BitLocker
et al
Nothing
new until
SQL 2016
Security

11. Security – SQL 2016
Cell level
TDE
Always Encrypted
Data Masking*
Row Level Security*
New!

12. Security – Always Encrypted
Enabled at column level
Protects data at rest *AND* in memory
Uses Column Master Key (client) and Column
Encryption Key (server)

13. Security – Always
Encrypted
Always!

14. Always Encrypted

15. Security – Always Encrypted
Deterministic – good for
static values; can be
indexed
• MUST use *_BIN2
collation
(Latin1_General_BIN2)
Randomized – better
security; cannot be
indexed
• Not allowed in WHERE
clause!

16. Security – Always Encrypted
text/ntext/image
XML/hierarchyid/geography/geometry
alias types/user-defined data types
SQL_VARIANT
rowversion (timestamp)
System alias (SYSNAME)
Computed columns
Identity columns
Sparse column sets
Temporal tables
Triggers (partial support)
Full text search
Replication
CDC
In Memory OLTP
Stretch database

17. Security – Always Encrypted
Foreign keys must match encryption
types
Client code needs to support AE
(currently this means .NET 4.6)

18. Security –
Always
Encrypted
Wizard

19. Why would a DB
Designer love it?
Always Encrypted, yeah.
Allows designers to not only
specify which columns need to be
protected, but how.
Built in to the engine, easier for
Devs

20. Security – Dynamic Data Masking
CREATE TABLE Membership(
MemberID int IDENTITY PRIMARY KEY,
FirstName varchar(100) MASKED WITH (FUNCTION = 'partial(1,"XXXXXXX",0)') NULL,
LastName varchar(100) NOT NULL,
Phone# varchar(12) MASKED WITH (FUNCTION = 'default()') NULL,
Email varchar(100) MASKED WITH (FUNCTION = 'email()') NULL);
INSERT Membership (FirstName, LastName, Phone#, Email) VALUES
('Roberto', 'Tamburello', '555.123.4567', 'RTamburello@contoso.com'),
('Janice', 'Galvin', '555.123.4568', 'JGalvin@contoso.com.co'),
('Zheng', 'Mu', '555.123.4569', 'ZMu@contoso.net');

21. Security – Dynamic Data Masking
Done at column level (NOT ENCRYPTION!)
Meant to complement other methods
Performed at the end of a database query right before
data returned
Performance impact small

22. Security – Dynamic Data Masking
4
functions
available
• Default
• Email
• Custom String
• Random

23. Security – Dynamic Data Masking
Data in database is not changed
Ad-hoc queries *can* expose data
Does not aim to prevent users from exposing
pieces of sensitive data

24. Security – Dynamic Data Masking
Cannot mask an encrypted column (AE)
Cannot be configured on computed column
But if computed column depends on a mask, then mask is
returned
Using SELECT INTO or INSERT INTO results in masked data
being inserted into target (also for import/export)

25. Security – Dynamic Data Masking

26. Why would a DB
Designer love it?
Allows central, reusable design
for standard masking
Offers more reliable masking and
more usable masking
Removes whining about “we can
do that later”

27. Security – Row Level Security
Filtering result sets (predicate based access)
Predicates applied when reading data
Can be used to block write access
User defined policies tied to inline table functions

28. Security – Row Level Security
No indication that results have been filtered
If all rows are filtered than NULL set returned
For block predicates, an error returned
Works even if you are dbo or db_owner role

29. Security – Row Level Security
Recommended to create schema for RLS objects
(predicate functions and security policies)
Use ALTER ANY SECURITY POLICY permissions;
this does not require SELECT on the columns
Avoid type conversions in predicate functions to
avoid runtime errors

30. Security – Row Level Security
Not
Allowed
• DBCC SHOW_STATISTICS
• FILESTREAM
• Polybase
• Indexed views
• CDC nor change tracking

31. Security – Row Level Security

32. Why would a DB
Designer love it?
Allows a designer to do this sort
of data protection IN THE
DATABASE, not just rely on code.
Many, many pieces of code.

33. Security - Summary
Key differences TDE AE DDM RLS
Encryption Y Y N N
Protect data in memory N Y N N
Overhead Low* High Low Low
Block updates N N N Y

34. Security - Summary
Data quality?
Data availability?
Data recovery?
Query performance?
Legal requirements?
Which one is right
for you?

36. Advanced Features and Updates
Love them all…

37. MOAR Foreign Keys!
What was the previous limit?
253
10,000
What is the new limit?

38. Why would a DB
Designer love it?
…not so sure ….

39. Columnstore Improvements
Filter on NCI Columstore
Updateable
In-memory tables can use
Table with Clustered Index Columnstore can have NCI
PKs and FKs constraints
Even more performance improvements

40. Why would a DB
Designer love it?
Faster
More options
Better

41. Advanced Features – Temporal Tables
ANSI SQL 2011 based
Current data
Access to historical data
Point-in-time analysis
Uses “period columns”
System-Versioned Temporal Tables

43. System Versioned Table: Temporal Table

44. System Versioned Table: Temporal Table

45. Why would a DB
Designer love it?
Don’t have hand-develop a
solution
SQL Server knows what these
tables are and can optimize itself
when it uses them.

46. Advance Features: JSON
Not a data type in SQL Server 2016
Results as JSON
Import JSON
Store JSON nvarchar()
Requires Compatibility Level 130
FOR JSON
OPENJSON

47. Why JSON?
It’s Hipster!
Common for data exchange
Common for persistence
Tools
Preferred

48. Getting JSON out…

49. SSMS

50. JSON – Getting it in

51. Why would a DB
Designer love it?
Don’t have hand-develop a
solution
Your Devs will Love you More
You can be faster and better
because you now speak a new
language 

52. Physical Files – Stretch Database
Stretch Database
• Migrate least used data to Azure
• Migrate some or entire table if desired
• Stretch database ensures no data is lost
• DMVs provided to show progress

53. Physical Files – Stretch Database
Stretch Database
• You can pause migration
• No change to queries
• Latency expected for querying
historical data

54. Physical Files – Stretch
Database

55. Stretch Database
Enable Remote Data Archive
Hot & Cold data
On-Prem & Cloud
EXEC sp_configure 'remote data archive' , '1'; GO RECONFIGURE;
GO

56. Why Stretch?
Smaller backups
Application ignorant
Performance on hot data
Performance* on cold data

57. Why not Stretch?
Uniqueness
Certain datatypes
Replication
View limitations
Index limitations
More…
Uniqueness is not enforced
for UNIQUE constraints
and PRIMARY KEY
constraints on a Stretch-
enabled table.

58. Why would a DB
Designer love it?
Don’t have hand-develop a
solution
It’s all automatic
Your devs will love you because
no app changes required.

59. Finally…
Many, many
performance
enhancements. It’s
just FASTER. No
design changes
needed.

60. One more time…
Every Design
Decision must
be based on
Cost, Benefit
and Risk

61. Thank you!
I’d appreciate feedback of any type about
this presentation.
KarenLopez@InfoAdvisors.com