Download Database Design

Database Design
Solving Problems Before They Start!
Edward Pollack, Database Optimization Engineer
Thank You
Gain insights through familiar
tools while balancing monitoring
and managing user created
content across structured and
unstructured sources.
www.microsoft.com
Presenting Sponsors
Unifying computer, storage,
networking, and virtualization, Cisco
UCS is the optimal database and
business intelligence platform for SQL
Server.
www.cisco.com
Supporting Sponsors
2
2
Solutions from Dell help you
monitor, manage, protect and
improve your SQL Server
environment.
www.software.dell.com
Planning on attending PASS Summit 2015? Start saving
today!
• The world’s largest gathering of SQL Server & BI professionals
• Take your SQL Server skills to the next level by learning from the world’s SQL
Server experts, in over 190 technical sessions
• Over 5000 attendees, representing 2000 companies, from 52 countries,
ready to network & learn
Contact your Local or Virtual Chapter for an
additional $150 discount.
$1795
until July 12th, 2015
Speaker Bio
Edward Pollack
Commerce Hub
Database Administrator
15 years of IT experience in servers, storage, database design,
optimization, and sharing it all with you.
[email protected]
@EdwardPollack
4
What is Good Design?
 Creating a meaningful data model (a purpose)

This data model should directly follow a business model
 Doing it right the first time!





Easier to create database structures than to change existing ones
Ensuring optimal & expected performance
Ability to scale for future growth
Intuitive/easy-to-understand structure
Avoiding the scorn of future DBAs and developers!
5
5
Tables
• Represent a distinct, specific entity
• “Double-duty” tables can be confusing and hard to work with
• Contains unique columns that are not repeated
• Repeated columns lead to confusion & bad data
• Each table is a unique instance of a business object
• Each row is a distinct instance of this entity
• Primary key ensures that this is always true
• Multiple schemas can classify tables & security
• Optional, but helpful for complex databases
• Tables facilitate meaningful relationships
6
6
Example: Types of Tables
Entity Table:
Lookup Table:
Linking Table:
7
7
Data Types
• When in doubt, use standards
 Eg: ISO 5218 for gender, ISO 3166 for country codes, ISO 4217 for currency codes, etc…
 Use the same standard for all similar columns in your database
•
•
•
•
Length/size of column should be accurate & scalable
Good data types prevent bad data!
Don’t substitute one data type for another (ie: string for date)
Boolean values should be bits
8
8
Naming Objects
• What is it?
• Do not name for location, time, usage, storage, or anything else!
• A data element is unique, therefore its name should be unique
• For example, don’t use “ID” for all primary key ID names
• Non-uniqueness can lead to confusion when joining tables
• Column names should never be negative!
• Ie: is_not_taxable, is_not_active, is_not_shipped, etc…
• Avoid spaces, system reserved words, and special characters
• Do not use arbitrary prefixes such as tbl, sp, usp, etc...without good reason
• Do not suffix with _delete, _old, _new, etc…
• Table names should be singular
9
9
The ERD: Entity Relationship Diagram
10
10
NULL vs. NOT NULL
• NULL = non-existence
• Do not make up “De-Nullifiers”
• Such as 1/1/1900, John Doe, ‘N/A’, ‘-1’, etc…
• NOT NULL = required in an application
• NULL has meaning, define this up front
• Beware: NULL behavior! ORDER BY, GROUP BY, =, <>, JOINs, etc…
• SET ANSI NULLS ON will be the only option in a future SQL Server version
•
•
This is an ISO standard---write/fix your code to use this!
WHERE X IS NULL (good) vs. WHERE X = NULL (not good)
11
11
Constraints
• Primary Key: Simple, narrow, and unique
• Foreign keys guarantee OLTP integrity
 ON DELETE/UPDATE maintains this, if needed
•
•
•
•
•
•
Check & foreign key constraints prevent bad data
Give the query optimizer helpful tools
Always name them---never use defaults
Provides feedback to developers
Default constraints are good when meaningful
Cost for constraints is paid on writes
12
12
Tips & Reminders






SQL Server is optimized for set-based queries. Avoid iteration!
OLAP vs. OLTP: Read-heavy vs. write-heavy tables.
Archiving? How to handle old or outdated data.
The database stores data. Applications format it!
Encrypt sensitive data in database & decrypt in the application.
Avoid SELECT *. Choose only the columns you need!
13
13
Normalization
• Data is normalized to avoid inconsistency
• 1NF: No table has repeating groups. Has a PK.
• 2NF: All tables can be defined by a single key
 Data only needs updating in a single place
 Enforces uniqueness on important relationships
• 3NF: Remove columns not dependent on key.
• …
• Normalization or denormalization should follow meaningful application
patterns ONLY!
14
14
Example: Normalization
15
15
Database Design: Conclusion
• Good design:
•
•
•
•
•
Saves immense time, effort, and money in the future
Allows for more efficient development
Makes documentation easy
Provides instant insight into a business model
Allows unexpected change to be handled with ease
• Future DBAs & Developers will see your initials and love you
16
16