Where Are My Keys?<br />Ami Levin | CTO | DBSophic LTD<br />
Session Goals<br />A revisit to some of the fundamental design principals of relational databases: Normalization rules, ke...
The Forefathers<br />
Normalization<br />“A relation whose domains are all simple can be represented in storage by a two-dimensional column homo...
1st Normal Form<br />There's no top-to-bottom or left-to-right ordering to the rows and columns<br />There are no duplicat...
1st Normal Form<br />
2nd Normal Form<br />R is in 1st Normal Form (1NF).<br />Given any candidate key K and any attribute A that is not a const...
2nd Normal Form<br />
3rd Normal Form<br />R is in second normal form (2NF)<br />Every non-prime attribute of R is non-transitively dependent on...
3rd Normal Form<br />
Keys<br />Simple<br />Composite 	<br />Candidate 	<br />Primary	<br />Artificial / Surrogate 	<br />Intelligent<br />Natur...
The Debate<br />To ID or not to ID?<br />IDENTITY (1,1) PK vs. Natural key<br />
Pro Artificial<br />In some cases, no natural key exists and an artificial key is the only option.<br />Examples?<br />
Pro Artificial<br />Natural keys can change. Artificial keys never change.<br />How Often?<br />Cascading referential cons...
Pro Artificial<br />Natural keys may become very long and complex.<br />Get longer with each level<br />900 Bytes limit in...
Pro Artificial<br />Artificial keys improve performance. <br />Simpler join predicates<br />Ever increasing clustering eff...
Pro Artificial<br />Artificial keys reduce clustered index fragmentation. <br />All types of artificial keys?<br />Minimiz...
Pro Natural<br />Natural keys have business meaning.<br />Artificial keys are logically never queried for<br />
Pro Natural<br />Queries on tables using natural keys require fewer joins.<br />The more familiar and meaningful the key, ...
Pro Natural<br />Data consistency is maintained explicitly when using natural keys.<br />Artificial keys enable logical du...
Pro Natural<br />Natural keys eliminate potential physical clustering performance issues.<br />Contention for clustered re...
Less Mentioned Issues<br />Artificial keys are the de-facto standard.<br />ORM generate artificial keys<br />LINQ doesn’t ...
Less Mentioned Issues<br />Data statistics and optimizations.<br />Statistics on artificial keys are useless for parameter...
Less Mentioned Issues<br />Modularity and portability.<br />Migration to other platforms<br />Merging with other databases...
Less Mentioned Issues<br />Simplicity and aesthetics.<br />
Demo Design Spec<br />URL<br />Country and city of owner<br />Country ISO code needed by application<br />Data consistency...
Natural vs. Artificial<br />DEMO<br />
Ask Yourself…<br />Is there a natural key that I can use as PK? <br />Are there a few natural candidates? <br />Which one ...
For More Information<br />A Relational Model of Data for Large Shared Data Banksby E. F. CODD.<br />The Relational Model f...
Where Are My Keys?<br />Q&A<br />
3   where are my keys - sql explore
Upcoming SlideShare
Loading in …5
×

3 where are my keys - sql explore

827 views
706 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
827
On SlideShare
0
From Embeds
0
Number of Embeds
169
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

3 where are my keys - sql explore

  1. 1. Where Are My Keys?<br />Ami Levin | CTO | DBSophic LTD<br />
  2. 2. Session Goals<br />A revisit to some of the fundamental design principals of relational databases: Normalization rules, key selection, and the controversies associated with these issues from a very practical, hands-on perspective, with special emphasis on some surprising performance issues that may arise from sub-optimal selection of keys... <br />
  3. 3. The Forefathers<br />
  4. 4. Normalization<br />“A relation whose domains are all simple can be represented in storage by a two-dimensional column homogeneous array of the kind discussed above. Some more complicated data structure is necessary for a relation with one or more non-simple domains. For this reason (and others to be cited below) the possibility of eliminating non-simple domains appears worth investigating. There is, in fact, a very simple elimination procedure, which we shall call…<br />normalization”<br />
  5. 5. 1st Normal Form<br />There's no top-to-bottom or left-to-right ordering to the rows and columns<br />There are no duplicate rows<br />Every row-column intersection contains exactly one value<br />All columns are regular<br />
  6. 6. 1st Normal Form<br />
  7. 7. 2nd Normal Form<br />R is in 1st Normal Form (1NF).<br />Given any candidate key K and any attribute A that is not a constituent of a candidate key, A depends upon the whole of K rather than just a part of it.<br />
  8. 8. 2nd Normal Form<br />
  9. 9. 3rd Normal Form<br />R is in second normal form (2NF)<br />Every non-prime attribute of R is non-transitively dependent on every candidate key of R.<br />A transitive dependency is a functional dependency, in which X -> Z (X determines Z) indirectly, by virtue of X -> Y and Y -> Z.<br />
  10. 10. 3rd Normal Form<br />
  11. 11. Keys<br />Simple<br />Composite <br />Candidate <br />Primary <br />Artificial / Surrogate <br />Intelligent<br />Natural<br />
  12. 12. The Debate<br />To ID or not to ID?<br />IDENTITY (1,1) PK vs. Natural key<br />
  13. 13. Pro Artificial<br />In some cases, no natural key exists and an artificial key is the only option.<br />Examples?<br />
  14. 14. Pro Artificial<br />Natural keys can change. Artificial keys never change.<br />How Often?<br />Cascading referential constraints<br />Artificial keys can change<br />
  15. 15. Pro Artificial<br />Natural keys may become very long and complex.<br />Get longer with each level<br />900 Bytes limit in SQL Server<br />Multi-column Joins<br />
  16. 16. Pro Artificial<br />Artificial keys improve performance. <br />Simpler join predicates<br />Ever increasing clustering effect<br />Short keys = Smaller DB = Faster (?)<br />
  17. 17. Pro Artificial<br />Artificial keys reduce clustered index fragmentation. <br />All types of artificial keys?<br />Minimize maintenance down time<br />What about deletes?<br />What about non-clustered indexes?<br />
  18. 18. Pro Natural<br />Natural keys have business meaning.<br />Artificial keys are logically never queried for<br />
  19. 19. Pro Natural<br />Queries on tables using natural keys require fewer joins.<br />The more familiar and meaningful the key, the less joins are required<br />“Bypass” joins across levels<br />
  20. 20. Pro Natural<br />Data consistency is maintained explicitly when using natural keys.<br />Artificial keys enable logical duplicates<br />
  21. 21. Pro Natural<br />Natural keys eliminate potential physical clustering performance issues.<br />Contention for clustered regions<br />
  22. 22. Less Mentioned Issues<br />Artificial keys are the de-facto standard.<br />ORM generate artificial keys<br />LINQ doesn’t cache composite key rows<br />
  23. 23. Less Mentioned Issues<br />Data statistics and optimizations.<br />Statistics on artificial keys are useless for parameter sniffing<br />Selectivity estimations on composite key statistics are less accurate <br />
  24. 24. Less Mentioned Issues<br />Modularity and portability.<br />Migration to other platforms<br />Merging with other databases<br />
  25. 25. Less Mentioned Issues<br />Simplicity and aesthetics.<br />
  26. 26. Demo Design Spec<br />URL<br />Country and city of owner<br />Country ISO code needed by application<br />Data consistency is crucial<br />
  27. 27. Natural vs. Artificial<br />DEMO<br />
  28. 28. Ask Yourself…<br />Is there a natural key that I can use as PK? <br />Are there a few natural candidates? <br />Which one is the simplest and most familiar?<br />How stable is it?<br />How will it be used logically?<br />What will be the table physical usage patterns?<br />What are the common query types for this table?<br />
  29. 29. For More Information<br />A Relational Model of Data for Large Shared Data Banksby E. F. CODD.<br />The Relational Model for Database Management: Version 2 by E.F. Codd. <br />An introduction to database systemsby C.J Date. <br />Database in Depth: Relational Theory for Practitionersby C.J Date.<br />The Database Relational Model: A Retrospective Review and Analysisby C.J Date.<br />Joe Celko's Data and Databases: Concepts in Practice by Joe Celko.<br />Joe Celko's SQL for Smarties, Fourth Edition: Advanced SQL Programmingby Joe Celko.<br />Database Modeling and Design, Fifth Edition: Logical Designby Toby J. Teorey, Sam S. Lightstone, Tom Nadeau, and H.V. Jagadish.<br />Pro SQL Server 2008 Relational Database Design and Implementationby Louis Davidson, Kevin Kline, Scott Klein, and Kurt Windisch.<br />
  30. 30. Where Are My Keys?<br />Q&A<br />

×