Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

The point here is that what happens in your indexes depends on the collation information you have
established for your data. Collation can be set at the database and column level, so you have a fairly fine
granularity in your level of control. If you’re going to assume that your server is case insensitive, then
you need to be sure that the documentation for your system deals with this, or you had better plan on a
lot of tech support calls — particularly if you’re selling outside of the United States. Imagine you’re an
independent software vendor (ISV) and you sell your product to a customer who installs it on an existing
server (which is going to seem like an entirely reasonable thing to the customer), but that existing
server happens to be an older server that’s set up as case sensitive. You’re going to get a support call
from one very unhappy customer.
B-Trees
Chapter 9: SQL Server Storage and Index Structures
Once the collation order has been set, changing it is very difficult (but possible), so
be certain of the collation order you want before you set it.
The concept of a Balanced Tree, or B-Tree, is certainly not one that was created with SQL Server. Indeed,
B-Trees are used in a very large number of indexing systems, both in and out of the database world.
A B-Tree simply attempts to provide a consistent and relatively low-cost method of finding your way to
a particular piece of information. The Balanced in the name is pretty much self-descriptive. A B-Tree is,
with the odd exception, self-balancing, meaning that every time the tree branches, approximately half
the data is on one side, and half is on the other side. The Tree in the name is also probably pretty obvious
at this point (hint: tree, branch — see a trend here?). It’s there because, when you draw the structure,
then turn it upside down, it has the general form of a tree.
A B-Tree starts at the root node (another stab at the tree analogy there, but not the last). This root node
can, if there is a small amount of data, point directly to the actual location of the data. In such a case, you
would end up with a structure that looked something like Figure 9-1.
So, we start at the root and look through the records until we find the last page that starts with a value
less than what we’re looking for. We then obtain a pointer to that node and look through it until we find
the row that we want.
In most situations though, there is too much data to reference from the root node, so the root node points
at intermediate nodes — or what are called non-leaf level nodes. Non-leaf level nodes are nodes that are
somewhere in between the root and the node that tells you where the data is physically stored. Non-leaf
level nodes can then point to other non-leaf level nodes, or to leaf level nodes (last tree analogy reference —
I promise). Leaf level nodes are the nodes where you obtain the real reference to the actual physical data.
Much like the leaf is the end of the line for navigating the tree, the node we get to at the leaf level is the end
of the line for our index. From there, we can go straight to the actual data node that has our data on it.
As you can see in Figure 9-2, we start with the root node just as before, then move to the node that starts
with the highest value that is equal to or less than what we’re looking for and is also in the next level
down. We then repeat the process: Look for the node that has the highest starting value at or below the
value for which we’re looking. We keep doing this, level by level down the tree, until we get to the leaf
level — from there we know the physical location of the data and can quickly navigate to it.
265