35
Richie Rump Jorriss LLC @Jorriss www.jorriss.net

Database Design Disasters

Embed Size (px)

Citation preview

Page 1: Database Design Disasters

Richie RumpJorriss LLC

@Jorrisswww.jorriss.net

Page 2: Database Design Disasters
Page 3: Database Design Disasters

• Think of your database as your application foundation.

• The more time you spend on your foundation the better your application will be.

• If you get the foundation wrong you WILL have problems.

Page 4: Database Design Disasters

• Databases are highly complex systems.

• SQL Server has over twenty years of development.

• Learning SQL Server is like Alice’s rabbit hole. It keeps going down.

• Leverage your DBAs experience and knowledge of SQL Server.

Page 5: Database Design Disasters

When they do SELECT * because it’s easier than naming the fields they need

Source: http://dbareactions.tumblr.com/post/41716132853/when-they-do-select-because-its-easier-than

Page 6: Database Design Disasters

When I see cursors written in new code

Source: http://dbareactions.tumblr.com/post/41643855887/when-i-see-cursors-written-in-new-code

Page 7: Database Design Disasters

When the job applicant can’t code FizzBuzz during the interview

Source: http://dbareactions.tumblr.com/post/40938657699/when-the-job-applicant-cant-code-fizzbuzz-during

Page 8: Database Design Disasters

• Single Table

• Wrong Types

• No Indexes on Foreign Keys

• Entity Attribute Value pattern

• Guids

• Surrogate Key / No Alternate Key

Page 9: Database Design Disasters

• All data is in one table

• Database Normalization is ignored.

• Redundant data everywhere

• Simple updates become complex

• Database changes become more frequent.

• Index strategy become messy

Page 10: Database Design Disasters
Page 11: Database Design Disasters

• Having the wrong data types can create long lasting issues.

• T-SQL can become challenging and inefficient.

• Understanding the differences between data types

• Better information, better decisions.

Page 12: Database Design Disasters

• CHAR – Fixed length. Value will be padded with spaces.

– Size n bytes.

– 1 – 8000 characters.

• VARCHAR – Variable length.

– The storage size is the actual length of the data entered + 2 bytes.

– 1 – 8000 characters.

Page 13: Database Design Disasters

• Holds UNICODE data.

• NCHAR– 1 – 4000 characters

– Storage size twice n characters.

• NVARCHAR– 1 – 4000 character

– Storage size twice n characters + 2 bytes.

Page 14: Database Design Disasters

• MAX allows a column size of 2GB.

• Cannot create an index on MAX columns

• REPEAT: Cannot create an index on MAX columns

Page 15: Database Design Disasters

• DATETIME – Accuracy rounded to .000, .003, or .007 second.

– 8 Bytes

• DATETIME2 (n)– Accuracy to .0000001 second

– 6 bytes for precisions less than 3;

– 7 bytes for precisions 3 and 4.

– All other precisions require 8 bytes.

Page 16: Database Design Disasters

• SMALLDATETIME – Accuracy to the minute.

– No seconds

– 4 bytes

• Demo

Page 17: Database Design Disasters

• BIGINT– -9,223,372,036,854,775,808 to

9,223,372,036,854,775,807

– Size 8 bytes

• INT

– -2,147,483,648 to 2,147,483,647

– Size 4 bytes

Page 18: Database Design Disasters

• SMALLINT– -32,768 to 32,767

– Size 2 bytes

• TINYINT

– 0 to 255

– Size 1 bytes

Page 19: Database Design Disasters

• Size matters

• Put the extra time to size it correctly

• Don’t forget indexes store data on disk

Page 20: Database Design Disasters

• BIT– Values can be 0 or 1 (or NULL)

– Size 1 byte

• TINYINT

– Values can be 0 to 255

– Size 1 byte

• Factor in your data access into your decision.

Page 21: Database Design Disasters

• May slow queries with JOINs

• Will have a performance impact on DELETEs

• Demo

Page 22: Database Design Disasters
Page 23: Database Design Disasters
Page 24: Database Design Disasters

Entity ID Name

1 Cecil Phillip

Attribute ID Entity ID Attribute Type Value

100 1 Phone Number 305-555-9607

101 1 Age 30

102 1 Birthdate 2/9/1983

Person

Person_Attribute

Page 25: Database Design Disasters

Entity ID Name

1 Cecil Phillip

Attribute ID Entity ID Attribute Type Value

100 1 Phone Number 305-555-9607

101 1 Age 501

102 1 Birthdate Yes I have one

Person

Person_Attribute

• No Data Type Enforcement

Page 26: Database Design Disasters

Entity ID Name

1 Cecil Phillip

Attribute ID Entity ID Attribute Type Value

100 1 Phone Number NULL

101 1 Age 30

102 1 Birthdate 2/9/1983

Person

Person_Attribute

• No NOT NULL Enforcement

Page 27: Database Design Disasters

• Querying much harder

• Demo…

Page 28: Database Design Disasters

• You would think this wouldn’t be a problem…

• Some benefits– Portable

– Id can be generated from the app

– That’s about it.

Page 29: Database Design Disasters

The problems:

• Size– Guids 16 bytes

– Int 4 bytes

– Disk and Memory

• Fragmentation

Page 30: Database Design Disasters

Source: http://blog.sqlauthority.com/2010/01/12/sql-server-fragmentation-detect-fragmentation-and-eliminate-fragmentation/

Page 31: Database Design Disasters
Page 32: Database Design Disasters

A partial solution:

• NEWSEQUENTIALID()

– Creates a sequential GUID.

– Minimizes fragmentation

– Still have the space issue.

Page 33: Database Design Disasters

• A surrogate key is a primary key automatically generated

• Surrogate keys are good thing.

• BUT when alternate key isn’t defined bad things can happen…bad things man, bad things.

• Demo…

Page 34: Database Design Disasters

• Data Model Resource Book vol 1-3 Len Silverston

• Pro SQL Server 2012 Relational Database Design and Implementation Louis Davidson, Jessica Moss

Page 35: Database Design Disasters

Richie Rump

@Jorriss

http://jorriss.net

http://slideshare.net/jorriss

http://dotnetmiami.com