Should I use a nullable int when working with int object IDs?

Question

If I'm working with, say, a BookID of type int in my code that corresponds to an int primary key field in a database table (I'm using C# and SQL Server)... is it best practice, when I'm passing around IDs in my code, to use a nullable int and check for null to see if the BookID exists:

if (BookID != null) {

or, is it a better practice to assign an integer value (such as 0 or -1) that cannot correspond to an actual value in the db:

if (BookID > 0) {

---

EDIT: For further clarification, suppose I only want to return the ID of the book, instead of the whole book object. In the db, the primary key is non-nullable, but if I were to perform a query for the BookID of 'my book title' that didn't exist, then I would get no results. Should this be reflected as null?

Example:

BookID = GetBookID("my book title");

Answer 1

I prefer to use a nullable int - this maps more directly to what will actually be in the database.

Also, there are many times when there are no appropriate values to use for null. Using -1 to signify null is bad practice, IMO, since -1 is often a valid value in a DB.

Answer 2

If you have a value that allows null in the database, you should use Nullable<T> and avoid introducing Magic Numbers. But if BookId is a (primary) key, it should probably not be nullable (besides it is used as a foreign key).

UPDATE

For the point of querying the database and not finding a matching record, there are several solutions. I prefer to throw an exception because it is usually an indication of an error if the application tries to get a record that does not exist.

Book book = Book.GetById(id);

What would you do in this case with a null return value? Probably the code after this line wants to do something with the book and in the case of null the method could usually do nothing more then

1. throwing an exception that could be better done in GetById() (besides the caller might have more context information on the exception)
2. returning immidiatly with null or an error code that requires handling by the caller, but that is effectivly reinventing an exception handling system

If it is absolutly valid, not to find a matching record, I suggest to use the TryGet pattern.

Book book;
if (Book.TryGetById(out book))
{
    DoStuffWith(book);
}
else
{
    DoStuffWithoutBook();
}

I believe this is better then returning null, because null is a kind of a magic value and I don't like to see implementation details (that a reference type or a nullable value type can take the special value named null) in the business logic. The drawback is that you lose composability - you can no longer write Book.GetById(id).Order(100, supplier).

The following gives you the composability back, but has a very big problem - the book could become deleted between the call to Exists() and GetById(), hence I strongly recommend not to use this pattern.

if (Book.Exists(id))
{
    Book book = Book.GetById(id).Order(100, supplier);
}
else
{
    DoStuffWithoutBook();
}

Answer 3

IMHO better to have (pseudocode)

public struct Identifier {

   private int? presistanceID;

   public Identifier(int presistanceID){
     presistanceID = presistanceID;
   }

   public bool IsSetted {
     get {presistanceID.hasvalue};
   }
}

if (book.BookID.IsSetted){
}

book.BookID.ToString();

This is way readable, provides basic type checking, allows two invariants (assigned ID and not assigned) and safe for NullRerenceException.

Answer 4

Sounds like a loaded question. The way you've asked it, yes for sure use a nullable int. The exception I can think of is if there is a lot of existing code that already uses/checks against 0 to represent not found. In that case consistency might be preferred. Nullable types are relatively new so seeing the 0 check is not unusual.