Brian Hartsock's Blog

On October 3rd, I encourage anyone who wants to learn about NHibernate to come to Richmond Code Camp. I will be giving a 100 level talk describing how to get started using it, and what it really is.

My initial idea is to create a fairly simple ASP.NET MVC application without persistence (use in memory Lists). And, in an hour, make it 100% persisted with transactions, lazy loading, etc. I am a little concerned it will be hard to teach NHibernate and get it done in an hour, but I am going to go for it. My goal is to touch on session factories, sessions, simple XML mapping, attribute mapping, inheritance relationships, associative relationships, criteria queries, HQL queries, and lazy loading. If I get through all that, I’ll throw in some custom types and maybe some fluent NHibernate since I have never used it but have wanted a reason to.

Any suggestions on things to show or things not to show?

I discovered one of the scariest performance problems with SQL Server I have ever seen today. This problem is so easy to over look, yet extremely detrimental to database performance.

Consider the following table.

BEGIN TRANSACTION
GO
CREATE TABLE dbo.Users
     (
     id int NOT NULL,
     username varchar(50) NOT NULL
     )
GO
ALTER TABLE dbo.Users ADD CONSTRAINT
     PK_Users_id PRIMARY KEY CLUSTERED
     (
     id
     )
 
GO
CREATE UNIQUE NONCLUSTERED INDEX IX_Users_username ON dbo.Users
     (
     username
     )
GO
COMMIT

Now look at the query plans of the following queries, that differ by a single character.

If you look closely, the query that uses an nvarchar parameter does an index scan while the one that users varchar does an index seek. This is very important, because an index seek is orders of magnitude faster than a scan.

The reason this occurs is because the parameter and column have different collation sets. Thankfully, I ran across this article which helped me solve the problem as it related to NHibernate.