Design Matters!

Design Matters!
The performance impact of design
Audrey Hammonds, SQL Server MVP
Global Sponsors:
Who Am I?
Audrey Hammonds
§ 
§ 
§ 
§ 
Data Services Consultant at Innovative Architects in Duluth, GA
SQL Server MVP
Admirer of Pretty Data Models
Student of Query Performance (translation: I’m still learning)
Contact: §  Twitter: @DataAudrey
§  Blog: http://Datachix.com (with Julie Smith - @JulieChix)
§  Email: [email protected]
Roads? Where we're going, we don't need roads. – Doc (Back to the Future Part II)
2
2
Platform & Environment
Hardware – Alienware M14x
§  CPU – Intel i7 (dual quad-core) @ 2.00 GHz
§  Memory – 8GB
§  Solid State Hard Drive
Software
§  SQL Server 2012 Enterprise Edition
§  AdventureWorks2012 (~200MB)
§  Embarcadero ERStudio Data Architect 9.1 (for model pictures)
Download Materials
http://sdrv.ms/DesignMatters
God isn't interested in technology. He cares nothing for the microchip or the silicon revolution. Look how he spends his time,
forty-three species of parrots! Nipples for men! –Evil (Time Bandits) 3
3
Presentation Structure
Database Design Concept
§  Done well
§  Done not-so-well
Query both models for identical result set
Illustrate performance impact
§  STATISTICS TIME
§  STATISTICS IO
§  Execution Plan
Other Unintended Consequences
§ 
§ 
§ 
§ 
Ugly Queries
Data Model Flexibility Data Quality
Biff becomes supreme overlord of Earth… Wait, what?
Well, Mr. Snelgrove, I happen to know that in the future I will not have the slightest use for algebra, and I speak from
experience. –Peggy Sue (Peggy Sue Got Married)
4
4
Performance Gain
Pain
5
LOGICAL DESIGN (Totally Unscien>fic, but S>ll PreDy True) PHYSICAL DESIGN 5
QUERY TUNING Benefits of Good Logical Design
Cleaner Data
Less Repeating Data
Fewer Opportunities for Poor Data Quality
More Options for Good Physical Tuning
More Flexible Query Tuning
… and Better Performance!
How I remember Third Normal Form: “My attributes will depend on the key, the whole key, and nothing but the key, so help
me Codd”
Sure, I could have stayed in the past. I could have even been king. But in my own way, I *am* king… Hail to the king, baby.
–Ash
(Army of Darkness)
6
6
Join Operators
Nested Loop Hash Match Merge Join For each row in the top
(outer) input, scan the
bottom (inner) input, and
output matching rows.
Use each row from the
top input to build a
hash table, and each
row from the bottom
input to probe into the
hash table, outputting
all matching rows.
Match rows from two
suitably sorted input
tables exploiting their
sort order.
Great when: Inner data
set is small, and outer
data set is well-indexed
Great when: Top input
(hash table) is relatively
small
Great when: Both data
sets are pre-sorted (as
in Clustered Index
scans)
Never interrupt me when I'm talking to myself. –McComb (Timecop)
7
7
Design Concepts
1.  Each entity should have a Primary Key
2.  Avoid repeating attributes and control data input
3.  Each attribute should describe the entity in one and
only one way (attributes are atomic)
4.  Entities are a concept/subject (noun) and attributes
describe entities (adjectives)
5.  Avoid repeating columns – if more than one type of
attribute is needed, resolve with a One-to-Many
(1:M) relationship
“Can't reinvent the wheel. But you can put your own spin on it.” – Lauren Beukes, The Shining Girls
8
8
Design Concept #1 – Primary Keys
Each entity should have a Primary Key
Uniquely identifies rows
More reliable join & aggregation operations
Consider clustered versus non-clustered primary keys
Clustered key – physically ordered
Non-Clustered key – not physically ordered
As you can see, Genghis very much enjoys Twinkies because of the excellent sugar rush. –Bill
(Bill & Ted’s Excellent Adventure)
9
9
Missing Primary Key in Lookup Table
Prett
y
10
Not So
Pretty
10
Unintended Consequences #1
Duplicated data
Bad query results
Complex aggregations
Table scans I got stabbed in the face with a fork, I saw it coming, I avoided it, I didn't avoid it, it happened to me in a different way. –Adam
(Hot Tub Time Machine)
11
11
Design Concept #2 – Lookup Tables
Repeating values within a table should be moved to a
lookup table
Controls input and data quality
Reduces data storage
I want you to remember this word, okay? It's kind of like a code word: Yahoo. Can you remember that? –John (Frequency)
12
12
Missing Lookup Table
Prett
y
13
Not So
Pretty
13
Unintended Consequences #2
Bad data / Bad results
Repeated data
Data scrubbing within query
Update to label (ex: US Pound to Pound – US) requires
multiple row update instead of single row update Wait a minute, Doc. Ah... Are you telling me that you built a time machine... out of a DeLorean? –Marty McFly (Back to the Future)
14
14
Design Concept #3 – Atomic Attributes
Each attribute should describe the entity in only one
way
Avoid multi-purpose columns
Do you wanna come with me? 'Cause if you do then I should warn you, you're gonna see all sorts of things. Ghosts from the past; Aliens
from the future… --The Doctor (Doctor Who)
15
15
Non-Atomic Data
Not So
Pretty
Prett
y
16
16
Unintended Consequences #3
Inflexible data
Dependent on string structure
Need LIKE or SUBSTRING to query information
Don't do anything I wouldn't do. And if you do, take pictures. –Al (Quantum Leap)
17
17
Design Concept #4 – Split Entities
An entity should represent one and only one subject
Avoid multiple entities for one subject if data from all is
queried together
In most cases, avoid elevating an attribute to an entity
(Exceptions: archives, projections, pending)
How to find this: Do I have mutually exclusive columns
in my table?
You were right, Philby. We did go too far. –Alexander (The Time Machine)
18
18
Split Entities
Not So
Pretty
Pretty
19
19
Unintended Consequences #4
More complex data model – Attribute has been elevated
to Entity definition
Less flexible – What happens when a third category pops
up?
Requires either UNION or multiple JOINs to get all data
Changing a Product from Manufactured to Stocked
requires data migration instead of attribute change
20
Keyboard. How quaint. –Scotty (Star Trek IV: The Voyage Home
20
Design Concept #5 – 1:M Relationships
Resolve 1-to-Many (1:M) relationships with child tables
– rather than more columns
Example: Business Rule: A person has one or more addresses
Good Model: Person entity with 1:M relationship to
PersonAddress entity
Not-so-Good Model: Person entity with repeating address columns
Alright you Primitive Screwheads, listen up! You see this? This... is my boomstick! The twelve-gauge double-barreled
Remington. S-Mart's top of the line. –Ash (Army of Darkness)
21
21
1:M Relationship
Prett
y
22
Not So
Pretty
22
Unintended Consequences #5
What happens when I want to add a new type of
attribute (ex: Billing Address)?
More columns
Queries modified
Decreased performance
Very ugly queries to get multiple addresses on rows
Unnecessarily wide tables
Ned, I would love to stay here and talk with you... but I'm not going to. –Phil (Groundhog Day)
23
23
In Conclusion…
Design Matters! Sell the theory by quantifying performance
Don’t forget unintended consequences
Thank you! Twitter: @DataAudrey
Blog: http://Datachix.com
Personal Email: [email protected]
Download: http://sdrv.ms/DesignMatters
Finally, I get to save the Earth with deadly laser blasts instead of deadly slide shows! –Al Gore (Futurama:
Bender’s Big Score)
24
24
Questions?
Global sponsors
Alliance sponsors
Thank You for Attending
Global sponsors
Alliance sponsors