What is the Difference between ROW_NUMBER, RANK and DENSE_RANK? Which one to use?

Ranking functions returns a ranking value for each row either in a partition, or not. We can produce the very same result for all functions, but they have different purpose.

In SQL Server there are 4 ranking functions:

ROW_NUMBER – Returns the sequential number of a row within a partition of a result set, without any gaps in the ranking. The rank of a row is one plus the number of distinct ranks that come before the row in question.

RANK – Returns the rank of each row within the partition of a result set. The rank of a row is one plus the number of ranks that come before the row in question.

DENSE_RANK – Returns the rank of rows within the partition of a result set, without any gaps in the ranking. The rank of a row is one plus the number of distinct ranks that come before the row in question.

NTILE – Distributes the rows in an ordered partition into a specified number of groups. The groups are numbered, starting at one. For each row, NTILE returns the number of the group to which the row belongs.

Let's see a simple example:

-- create table

CREATE TABLE dbo.Grades

(

Names VARCHAR(1),

Grade INT

)

GO

-- insert data

INSERT INTO dbo.Grades

VALUES ('A',100),('B',90),('C',80),('D',70),('E',70),('F',60)

GO

This query explains usage of all the four function together in one query.

-- Test the data

SELECT Names,

     Grade,

     ROW_NUMBER () OVER (ORDER BY Grade DESC) as ROW_NUMBER,

       RANK () OVER (ORDER BY Grade DESC) as RANK,

       DENSE_RANK () OVER (ORDER BY Grade DESC) as DENSE_RANK,

       NTILE(3) OVER(ORDER BY Grade desc) AS NTILE

FROM dbo.Grades

The results:

As you can see, ROW_NUMBER returns a serial number for each row, without any gaps. The numbers returned by the DENSE_RANK function do not have gaps and always have consecutive ranks. The RANK function does not always return consecutive integer. The NTILE, since I've specified 2 in the parameter, it divided all data into 2 groups.

Problem:

A classic problem when SQL Server Agent runs tasks like SSIS, DTS etc…, it's uses the agent service account by default. This account may not have access to a file share or database server that is necessary to successfully run the task. Proxy accounts in SQL Server 2008 allow you to circumvent this problem.

Solution:

With a proxy account, you can assign a job to use an account other than the SQL Server Agent account. Creating a proxy account is a two – step process. First, you must create a credential that will allow a user to use an Active Directory account that is not their own, Then, you specify how that account may be used.

A proxy can be defined with one or more sub-systems. The list of sub-systems is as follows:

@subsystem_id = 2 – ActiveX Script

@subsystem_id = 3 – Operating System (CMD Exec)

@subsystem_id = 4 – Replication Snapshot

@subsystem_id = 5 – Replication Distributor

@subsystem_id = 6 – Replication Transaction-Log Reader

@subsystem_id = 7 – Replication Merge

@subsystem_id = 8 – Replication Queue Reader

@subsystem_id = 9 – SQL Server Analysis Services Query

@subsystem_id = 10 – SQL Server Analysis Services Command

@subsystem_id = 11 – SQL Server Integration Services Package

@subsystem_id = 12 – Unassigned Proxy

As a first step for setting up a proxy account, we need to create a credential.

USE [master]

GO

CREATE CREDENTIAL [MyCredential] WITH IDENTITY = N'Domain\asaf', SECRET = N'Password'

GO

Now, let's create a proxy account.

USE [msdb]

GO

EXEC msdb.dbo.sp_add_proxy @proxy_name=N'MyProxy',

   @credential_name=N'MyCredential',

         @enabled=1

GO

This proxy will be used to run Operating System commands (@subsystem_id=11).

EXEC msdb.dbo.sp_grant_proxy_to_subsystem @proxy_name=N'MyProxy',                                   @subsystem_id=11

GO

EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'MyProxy',                                 @msdb_role=N'SQLAgentUserRole'

GO

Once the proxy exists it can be selected in setting up a job task by specifying the new proxy in the Run As dropdown in the task dialog.

Notes

-SQL Server Agent impersonates the credentials associated with the proxy to run the job step if it has been defined to use the proxy instead of using the default security context of SQL Server Agent Service account.

-When you create a job step to execute T-SQL, you cannot define a proxy because T-SQL does not use proxies but rather it runs under the security context of the job owner. If you want to change the security context for Transact-SQL job step, you can use the database_user_name parameter of sp_add_jobstep system stored procedure.

-You need to be sysadmin to create, modify or delete proxy accounts. However to use it, you need to be sysadmin or a member of either of these SQL Server Agent fixed database roles: SQLAgentUserRole, SQLAgentReaderRole, or SQLAgentOperatorRole.

Synonyms were first introduced in SQL 2005 and prove to be a great feature so far. A Synonym is a database object that serves the following purposes:

-Synonyms provide a layer of abstraction over the referenced object

-Allow changes to complicated (multi part) and lengthy names with a simplified  alias as a same server resident object.

-Provides flexibility for changing the location of objects without changing existing code.

-Synonyms can be created in the same database to provide backward compatibility for older applications in case of drop or rename of objects.

-Synonyms can be useful if you give the front-end query tools like spreadsheets and Access linked tables direct links in to the tables.

This helps because it allows you to move objects like tables, procedures to other locations without having to change the existing objects that reference them.

For example, consider the Employee table of the AdventureWorks sample database, located on a server named Server1. To reference this table from another server, Server2, a client application would have to use the four-part name Server1.AdventureWorks.HumanResources.Employee. Also, if the location of the table were to change, for example, to another server, the client application would have to be modified to reflect that change.

To address both these issues, you can create a synonym, EmpTable, on Server2 for the Employee table on Server1.

USE AdventureWorks;

GO

CREATE SYNONYM EmpTable

FOR Server1.AdventureWorks.HumanResources.Employee;

GO

USE AdventureWorks;

GO

SELECT TOP 5 *

FROM EmpTable;

GO

Now, the client application only has to use the single-part name, EmpTable, to reference the Employee table. Also, if the location of the Employee table changes, you will have to modify the synonym, EmpTable, to point to the new location of the Employee table. Because there is no ALTER synonym statement, you first have to drop the synonym, EmpTable, and then re-create the synonym with the same name, but point the synonym to the new location of Employee.

USE AdventureWorks;

GO

DROP SYNONYM EmpTable;

GO

CREATE SYNONYM EmpTable

FOR Server3.AdventureWorks.HumanResources.Employee;

GO

A synonym belongs to a schema, and like other objects in a schema, the name of a Synonym must be unique. You can create synonyms for the following database objects:

-Tables

-Views

-Assembly Stored Procedures, Table Valued Functions, Aggregations

-SQL Scalar Functions

-SQL Stored Procedures

-SQL Table Valued Functions

-SQL Inline-Table-Valued Functions

-Local and Global Temporary Tables

-Replication-filter-procedures

-Extended Stored Procedures

Additionally synonyms can be used only to change data of object not the schema of the object. Synonyms can be used with only SELECT, UPDATE, INSERT, DELETE, EXECUTE commands.

Limitations:

-You can delete a synonym without getting any warning that it is being referenced by any other database object.

-The object for which the synonym is being created is checked at run time. It is not checked at creation time. So this means that if you make any related error e.g. spelling error, the synonym will created, but you will get an error while accessing the object.

One of the coolest and fantastic new features of SQL Server 2008 is the new data type HierarchyID. You’ve probably been confronted with a scenario in which you needed to data tree of some sort, and you’ve probably struggled with joins, recursive operations, and other strategies in the past. With this new type you can implement tree structures with ease, making use of the best indexing strategy.

The HierarchyID data type allows you to construct relationships among data elements within a table, specifically to represent a position in a hierarchy.

Some Facts:

-New system CLR type supporting trees.

-Extremely compact – Internally stored as varbinary <= 900 bytes.

-Easy to understand – Holds a path that provides a topological sort of a tree.

-Has a set of methods that provide tree functionality: GetAncestor, GetDescendant,  GetLevel, GetRoot, IsDescendant, Parse, Read, Reparent, ToString, Write.

-Efficient querying that can utilize depth-first and breadth-first indexes.

The hierarchyid data type has the following limitations:

-A column of type hierarchyid does not automatically represent a  tree. It is up to the application to generate and assign hierarchyid values in such a way that the desired relationship between rows is reflected in the values. Some applications might not even want to have a column of type hierarchyid represent a tree. Perhaps the values are references to location in a hierarchy defined in another table.

-It is up to the application to manage concurrency in generating and assigning hierarchyid values. There is no guarantee that hierarchyid values in a column are unique unless the application uses a unique key constraint or enforces uniqueness itself through its own logic.

-Hierarchical relationships represented by hierarchyid values are not enforced like a foreign key relationship. It is possible and sometimes appropriate to have a hierarchical relationship where A has a child B, and then A is deleted leaving B with a relationship to a nonexistent record. If this behavior is unacceptable, the application must query for descendants before deleting parents.

Methods provided are as follows:

GetAncestor: Returns a HierarchyID that represents the n^th ancestor of this HierarchyID node.

GetDescendant: Returns a child node of this HierarchyID node.

GetLevel: Returns an integer that represents the depth of this HierarchyID node in the overall hierarchy.

GetRoot: Returns the root HierarchyID node of this hierarchy tree. Static.

IsDescendant: Returns true if the passed-in child node is a descendant of this HierarchyID node.

Parse: Converts a string representation of a hierarchy to a HierarchyID value. Static.

Reparent: Moves a node of a hierarchy to a new location within the hierarchy.

ToString: Returns a string that contains the logical representation of this HierarchyID.

Indexing Strategies :

There are two strategies for indexing hierarchical data:

-Depth-first

A depth-first index, rows in a subtree are stored near each other. For example, all employees that report through a manager are stored near their managers' record- Useful for querying subtrees.

-Breadth-first

A breadth-first stores the rows each level of the hierarchy together. For example, the records of employees who directly report to the same manager are stored near each other – Useful for querying immediate children.

Everyone found that genius but a lot broke their teeth using it in real life so let's 

Try it:

Let's assume we already have the following products 

The Idea is to represent a product tree:

First, we need to create a table to store the product hierarchy:

   1: CREATE TABLE dbo.ProductTree

   2: (

   3: [hierarchyid] [hierarchyid] NOT NULL,

   4: [Node] [nvarchar](4000) NOT NULL, --String representation of the HierarchyID.

   5: [ProductID] [int] NOT NULL

   6: )ON [PRIMARY]

   7: GO

   8: CREATE UNIQUE CLUSTERED INDEX [IX_ProductTree] ON dbo.ProductTree

   9: (

  10:  [hierarchyid],

  11:  [ProductID]

  12: )

  13: GO

Let's start building the tree! First, the root: 

   1: --Insert The Root -> Product

   2: INSERT INTO dbo.ProductTree

   3: (hierarchyid, Node, ProductID)

   4: VALUES

   5: (hierarchyid::GetRoot(), hierarchyid::GetRoot().ToString(), 1)

   6: GO

Notice the call GetRoot() to get the root node reference.

So now we have the root node, now we need to add the first child:

   1: --Insert First Child(IPhone)

   2: DECLARE @ProductID INT = 2 -- The First Child  = iPhone

   3: DECLARE @hierarchyid HIERARCHYID

   4: DECLARE @Parenthierarchyid HIERARCHYID

   5:

   6: --Get Parent hierarchyid

   7: SELECT @Parenthierarchyid = hierarchyid

   8: FROM dbo.ProductTree

   9: WHERE ProductID = 1

  10:

  11: --Get the hierarchyid

  12: SELECT @hierarchyid = @Parenthierarchyid.GetDescendant(NULL,NULL)

  13: FROM dbo.ProductTree

  14:

  15: --Insert First Child(IPhone)

  16: INSERT INTO dbo.ProductTree

  17: (hierarchyid, Node, ProductID)

  18: VALUES

  19: (@hierarchyid, @hierarchyid.ToString(), @ProductID)

  20:  Go

Notice the call GetDescendant() to get the descendant of a given node. 

It has a great significance in terms of finding the new descendant position 

Get the descendants etc.

We'll be inserting the "Mac", in the same level, below "Product" 

And next to "iPhone".

   1: --Insert Second Child(Mac)

   2: DECLARE @ProductID INT = 3 -- The Second Child = Mac

   3: DECLARE @FirstChildhierarchyid HIERARCHYID

   4: DECLARE @hierarchyid HIERARCHYID

   5: DECLARE @Parenthierarchyid HIERARCHYID

   6: --Get First Child hierarchyid and Parent hierarchyid

   7: SELECT @FirstChildhierarchyid = hierarchyid,

   8:        @Parenthierarchyid = hierarchyid.GetAncestor(hierarchyid.GetLevel())

   9: FROM dbo.ProductTree

  10: WHERE ProductID = 2 -- iPhone

  11: --Get the hierarchyid

  12: SELECT @hierarchyid = @Parenthierarchyid.GetDescendant(@FirstChildhierarchyid,NULL)

  13: FROM dbo.ProductTree

  14: --Insert Second Child(Mac)

  15: INSERT INTO dbo.ProductTree

  16: (hierarchyid, Node, ProductID)

  17: VALUES

  18: (@hierarchyid, @hierarchyid.ToString(), @ProductID)

  19:

  20: Go

Notice the call GetAncestor() to get the ancestor 

Of a given child node by the level (int).

Since we needed to add a new product,

At the same level of the "iPhone" product,

we had to get a node reference next to it, hence the @Parenthierarchyid.GetDescendant(@FirstChildhierarchyid,NULL).

Now let's add a second level child to "iPhone":

   1: --Insert Second Level Child(iPhone 4S)

   2: DECLARE @ProductID INT = 4 -- The Second Level Child = iPhone 4S

   3: DECLARE @hierarchyid HIERARCHYID

   4: DECLARE @Parenthierarchyid HIERARCHYID

   5: --Get the Parent hierarchyid

   6: SELECT @Parenthierarchyid = hierarchyid

   7: FROM dbo.ProductTree

   8: WHERE ProductID = 2 -- iPhone

   9: --Get the hierarchyid

  10: SELECT @hierarchyid = @Parenthierarchyid.GetDescendant(NULL,NULL)

  11: FROM dbo.ProductTree

  12: --Insert Second Level Child(iPhone 4S)

  13: INSERT INTO dbo.ProductTree

  14: (hierarchyid, Node, ProductID)

  15: VALUES

  16: (@hierarchyid, @hierarchyid.ToString(), @ProductID)

  17: Go

Here is the result:

?Notice the path representation and how it all fits in. Pretty neat huh
Conclusion

According performances, you can use the HierarchyID type without hesitation when modeling tree structures in a relational database. That new type fulfills its goal although it's not simple to implement…

...Hope you like this article I will write more about HierarchyID very soon

שלום לכולם, אני אסף אביב.

נכנסתי לעולם בסיסי הנתונים לפני 4 שנים ופשוט התאהבתי. במסגרת תפקידי כ-DBA, הספקתי לספק שירותי ייעוץ למספר חברות מובילות בארץ ובעולם, במספר תחומים שונים ומגוונים של מוצרי SQL Server.

אשמח לענות לשאלות בפורום וכמובן לנסות ולחדש באמצעות מאמרים.

אז נשתמע,
אסף