Design Matters! The performance impact of design. Audrey Hammonds, SQL Server MVP. Global Sponsors:

Transcription

1 Design Matters! The performance impact of design Audrey Hammonds, SQL Server MVP Global Sponsors:

2 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: Blog: (with Julie Smith audreydhammonds@gmail.com Roads? Where we're going, we don't need roads. Doc (Back to the Future Part II) 2 2

3 Platform & Environment Hardware Alienware M14x CPU Intel i7 (dual 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 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

4 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

5 Performance Gain Pain (Totally Unscien>fic, but S>ll PreDy True) 5 LOGICAL DESIGN PHYSICAL DESIGN QUERY TUNING 5

6 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

7 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. Great when: Inner data set is small, and outer data set is well-indexed 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. Great when: Top input (hash table) is relatively small Match rows from two suitably sorted input tables exploiting their sort order. Great when: Both data sets are pre-sorted (as in Clustered Index scans) 7 Never interrupt me when I'm talking to myself. McComb (Timecop) 7

8 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 8 Can't reinvent the wheel. But you can put your own spin on it. Lauren Beukes, The Shining Girls 8

9 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

10 Missing Primary Key in Lookup Table Prett y Not So Pretty 10 10

11 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

12 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

13 Missing Lookup Table Prett y Not So Pretty 13 13

14 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

15 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

16 Non-Atomic Data Prett y Not So Pretty 16 16

17 Unintended Consequences #3 Inflexible data Dependent on string structure Need LIKE or SUBSTRING to query information 17 Don't do anything I wouldn't do. And if you do, take pictures. Al (Quantum Leap) 17

18 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? 18 You were right, Philby. We did go too far. Alexander (The Time Machine) 18

19 Split Entities Pretty Not So Pretty 19 19

20 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

21 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

22 1:M Relationship Prett y Not So Pretty 22 22

23 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 23 Ned, I would love to stay here and talk with you... but I'm not going to. Phil (Groundhog Day) 23

24 In Conclusion Design Matters! Sell the theory by quantifying performance Don t forget unintended consequences Thank you! Blog: Personal audreydhammonds@gmail.com Download: 24 Finally, I get to save the Earth with deadly laser blasts instead of deadly slide shows! Al Gore (Futurama: Bender s Big Score) 24

25 Questions? Global sponsors Alliance sponsors

26 Thank You for Attending Global sponsors Alliance sponsors