Does creating an index on a text column make search costlier? - sql-server

Question

Does having a string column as the primary key instead of an integer column adversely affect search times and/or insertion times?
Scenarios
a. A common scenario for any application is to make this query every time someone creates a new user account:
Does that user name already exist or is it taken by someone else?
b. And when a person logs in, another query that looks up the user name is required to be made like so:
Does a row with that UserName exist in the User table?
c. Similarly, when a user says they've forgotten their password, we need to search based on their email.
Does a row with that Email exist in the User table?
d. It is only in the case of linking up the User table with other user related tables such as UserRole, UserClaim, etc. that we may need to join them based on an integer Id like so:
SELECT *
FROM User, UserClaim
WHERE User.Id = UserClaim.UserId;
Having an Integer as the Primary Key vs. Having a String as the Primary Key
Till now, I've always just had a user table with an integer primary key (and clustered index thereon), like so:
User
-----
Id int primary key identity(1, 1),
UserName nvarchar(50) not null,
Email nvarchar(100) not null,
PasswordHash nvarchar(32) not null
However, now contemplating over the use-cases I described above, I am wondering if it is more fruitful to instead completely eliminate the integer primary key and instead make one of the UserName or Email field as the primary key like so:
User
-----
UserName nvarchar(50) primary key,
Email nvarchar(100) not null,
PasswordHash nvarchar(32) not null
That would create a clustered index on the UserName field probably speeding up queries in scenarios a and b listed above, but I am not sure of the impact scenarios c and d because that would depend on the speed or comparing integers with speed of comparing indices based on a string column.
Questions
However, that leaves me with a few lose ends I need to tie up before I can commit on this design:
Does making a clustered index on a text field like the above have any performance implications? How does it effect insertion times? Search times?
I would imagine creating an index on an integer is faster than on a string?
We can have only one clustered index. If I allow my users to login using either a user name or email, anyone they like, then I am going to have to make searches on both the UserName and Email fields just as frequently. How do I manage that? Should I make a non-clustered index on the Email field?
Would having a string column as the primary key have an impact on performance of the joins I do with other link tables like so:
SELECT * FROM User, UserRole
WHERE User.UserName = UserRole.UserName;
Considering #3, it looks like I should just keep the integer Id column in the User table and create a non-clustered index each on the UserName and Email columns?
I am using Microsoft SQL Server 2014.

Answer 1

Does making a clustered index on a text field like the above have any
performance implications? How does it affect insertion times? Search
times?
Every row of every non-clustered index will contain the clustered index key as rowkey. INT = 4 bytes, your unicode string column Email can potentially occupy NVARCHAR(100) = up to 200 bytes.
Clustered indexes are good for range scans. Range scan on email addresses are hardly expected.
An identity-based clustered index is an of warranty close to zero fragmentation and fast inserts, due to an absence of page splits
We can have only one clustered index. If I allow my users to login
using either a user name or email, anyone they like, then I am going
to have to make searches on both the UserName and Email fields just as
frequently. How do I manage that? Should I make a non-clustered index
on the Email field?
Yes, if you will decide to make a unique clustered index on UserName, you will want to have another nonclustered index on Email. If a user will search by Email column, column username will be part of such index automatically (because of the reason explained in a point above) and such index will be covered.
Would having a string column as the primary key have an impact on
performance of the joins
A clustered index on UserName column is optimal for such joins, because it will keep data preordered, so on large datasets instead HASH joins are more likely to be replaced by MERGE joins
Considering #3, it looks like I should just keep the integer Id column
in the User table and create a non-clustered index each on the
UserName and Email columns?
It very much depends on your workload. If you have to frequently join that table on a column UserName, it can be that clustered index on such column will work for you. In that case, you can make a non-clustered unique index on a field Email and keep a primary key on ID but make it non-clustered also
(This post is based pretty much on personal opinion)