Tuesday, October 24, 2006

The Cost of GUIDs as Primary Keys

Today I've read an excellent article written by Jimmy Nilsson about The Cost of GUIDs as Primary Keys. A must-read article when your using GUIDs as primary keys in your database.

I must admit that I have been always against using GUIDs as a primary key because of the bad performance you get when having tables with lots of records. After reading this article, I believe that COMBs will solve this issue.

PS: I can strongly recommend you to get a copy of Applying Domain-Driven Design and Patterns. Two thumbs up!

Saturday, October 07, 2006

To test or ... to test?

I recently came across the .NET Mock Objects project. This framework supplies mock implementations of the ADO.NET generic interfaces like IDataReader, IDbConnection, etc. (currently .NET 1.1 only). At first I liked this approach. It enabled me to test my data access layer without the actual database that I was using.

When mocking out the database, you have unit tests with all PC-COF characteristics. They are lean, mean, fast running unit tests that can be run with each compilation of your code.

As I already mentioned, at first I was really into this concept. But then I came down to earth and asked myself the following question: Is it really useful to test a data access layer without it's underlying infrastructure?

Actually, no! What's the other alternative? Well, the alternative is creating integration tests that incorporates the database as well. I'm convinced that this is the more appropriate way to test a data access layer.

I recently discovered a bug in the DB2DataReader class. I could never have discovered this bug without developing integration tests for my data access layer. If I used a mocked version of my data access helper classes (something similar like the Data Access Application Block of the Enterprise Library) then this issue will not surface and my tests will run fine.

The downside of integration tests is that you are not going to run them on every compilation of your code, but only a couple of times a day. This because they take a lot of time to run compared to regular unit tests. They also require configuration before anyone can run them.

Jeremy D. Miller (The Shade Tree Developer) has a really interesting article regarding this matter.

I have come to conclusion that writing tests for your data access classes is a must, but that it is useless until you incorporate the database itself. This code has no reason of existence without a database. Instead of using .NET Mock Objects, I am investigating what XtUnit can do for me.

As a final note I would kindly ask the reader of my blog to share his experience regarding this matter.