1. Tweet Tweet – What Developers
Need to Know About SQL Server
Brent Ozar
SQL Server DBA, Microsoft MVP
Microsoft Certified Master of SQL Server

2. Intro
I recently hosted a Twitter Chat on everything developers would need to know
about designing databases. I was joined by Richard Douglas, a SQL server for
Dell Software and also the Editor in Chief of SQLServerpedia.com.
We asked our followers and participants to share their tips and best practices
using the hashtag: #dellsql. The following slideshow content is what we
deemed as most useful to our audience. Enjoy!
2
Room for text
Global Marketing

3. @SQLintheWild says “Get it Right the First Time”
• Understand the changing database
design from the beginning
Remember
• As your app grows and more stuff
interfaces with it, simply refactoring
the database is no longer an option
3
Room for text
Global Marketing

4. @alzdba says “Use the Right Data Types”
• Tell the database when a field is
unique and relates to a field in
another table
• Set up constraints or foreign key
relationships
Remember
• This can actually make your queries
faster because SQL Server uses this
knowledge to build better execution
plans
4
Room for text
Global Marketing

5. @MarkStacey says “Use DATE if You Don’t Need Time”
• DATE is a narrower field
than DATETIME, requiring
less storage.
Remember
• You can pack more rows
per page on your date
indexes
5
Room for text
Global Marketing

6. @RealSQLGuy says “NVACHAR is Not an All-Purpose
Datatype”
• Use the bare minimum and size data
needs
Remember
• NVARCHAR is Unicode, which uses
2x the storage space for as
compared to just plain VARCHAR.
• This means you can cache half as
many rows in memory, plus your
storage IO takes twice as long
6
Room for text
Global Marketing

7. @SirSQL says “Blobs Rarely Belong in the Database”
• Varbinary (max) should be an
anomaly
Remember
• Licensing databases is way
more expensive than
licensing a file server
7
Room for text
Global Marketing

8. @Ruirrib says “Not all Types are Good for Primary Keys”
• Primary keys & clustering keys
should be:
– Narrow
– Static
– Ever-increasing
Remember
• Don’t go redesigning an existing
database to change this,
because it’s probably not your
biggest bottleneck
8
Room for text
Global Marketing

9. @dpenton says “If Your First Inclination is to use a Trigger,
Stop”
• Believe it or not, you could be
viewing the problem wrong
• Consider moving to an asynchronous
solution
9
Room for text
Global Marketing

10. @RealSQLGuy says “There’s No Need for an Index on
Every Column in the Table”
• Narrow, one-field indexes are usually
less useful
Remember
• If you insert a record into a table with
10 non-clustered indexes, you’ll be
doing 11 (or more) writes to disk each
time. Why bother if you could save
time with one-field indexes?
10
Room for text
Global Marketing

11. @Nick Craver says “Don’t Run SSMS Index Suggestions
Blindly”
• SQL SMS’s index suggestions have
no concerns about adding overhead
to inserts/updates/deletes
Remember
• More often than not, they’re
supersets or subsets of existing
indexes
11
Room for text
Global Marketing

12. @SQLintheWild says “Know the Common Queries that Run
Against Indexes for Table Structures”
• Word to the wise: don’t go crazy
adding indexes with guesses when
you first get started with a new
database
Remember
• Indexes are easy to add later – wait to
see how the queries actually shape
up
12
Room for text
Global Marketing

13. For More Information
• To view the twitter chat, go to: http://bit.ly/HVh4m3
• To learn more about Solutions for SQL Server: http://dell.to/1cxeM7Q
13
Room for text
Global Marketing