Let us continue our question of the day series with day four.

What is the difference between a primary key and a unique key?

The unique key and the primary key designation both enforce that the particular column is unique.  However, the primary key will create a clustered index using that column and a unique key will create a non-clustered index.  This is the fundamental difference in the two.  Another minor difference is that the unique key allows you to have one null value and the primary key does not allow any use of the null value.

Enjoy!

Today we continue our Question of the Day series with question number three.  In case you are just joining us, we are doing a question a day as an exercise in SQL Learning.

What is fill factor?

My first response to this question in normal day-to-day conversation is that fill factor is a great SQL guy that I follow on twitter.   All joking aside, fill factor is an option that will determine how full to create each index page.  In other words, when the index page is filling up and does not have enough room to insert a new row, then SQL Server will generate a new index page and move some of the rows from the last index page to this new page.  This is known as a page split.  If we use the fill factor option, then the server will reserve a set amount of space on each index page and thus will reduce the number of page splits.  The default value for fill factor is 0.

Enjoy!

Today we continue our series with our second question of the day.

What is the difference between a clustered and non-clustered index?

In simplest terms, a clustered index is the actual data, reordering the way that the records are physically stored.  Because of this, each table can only contain one clustered index.

However, a non-clustered index is more like a pointer to the actual record.  The logical order of the non-clustered index does not usually match how the data is stored physically.

There is also a third option, the heap, which is a table without an index at all.  Without an index, the server would have to read through all of the records in order to find the data queried.  Enjoy!

For the next week, I will be on vacation and then when I return I have a big project that needs my full attention.  However, being dedicated to blogging daily I thought it might be an interesting little journey for remainder of the month of August would be to post a question of the day with the answer.  I am not trying to steal any thunder from the SQL Server Central QotD where you test your skills for points against the world.  This will be simply an exercise in SQL learning.

So let us begin with day one…

What is normalization?

In simplest terms it is the organizing of data in a relational database to reduce the duplication of data.  In order to accomplish this we would split one large record entity into smaller tables that are linked by their relationship.  For example, if you had a simple database that stored orders of widgets.  You would have a table that contained customer data and a table for order information.  You would not want to store customer contact information in each record of the order table.  There would be one customer record and then possibly multiple order records linked by a customer ID field to ensure a relationship and preventing you from redundant customer contact information in each order record.  However, to the user who receives an invoice that contains his order and his contact information the data seems to be one contiguous unit.

Just in case you did not know, this theory was pioneered by E. F. Codd in 1970.  Enjoy!

Paul Randal (blog|twitter) did a wonderful month-long series on the Myths and Misconceptions with SQL Server a couple of years back and I thought it would make an excellent read for the Schoolhouse.  Here is the link for the 60 page completely documented PDF version of the blog series.  Enjoy!

SQL Schoolhouse!

Today’s installment of the Saturday SQL Schoolhouse is brought to you by the fine folks over at Microsoft.  When searching for a topic to “teach” today in the schoolhouse, I came across this site called Microsoft Case Studies and could not stop reading.  Obviously, it makes perfect sense for Microsoft to create such a page to help business see the correlation between their products and solving the problems that they have.

Being a SQL geek, I was enthralled like when you are reading a good spy novel wondering if the migration was successful, did the BI solution solve their reporting quandary, did the cloud really save them millions in unnecessary overhead.  Forget the kindle, pick up a good case study and it may help you solve a problem you are having in your office.  Enjoy!