Geek Answers Handbook

Should I use nullable int when working with identifiers of int objects?

If I work with, say, a BookID of type int in my code that matches the int primary key field in the database table (I use C # and SQL Server) ... it is best practice when I pass identifiers in my code so that use nullable int and check for null to see if BookID exists:

if (BookID != null) {

or, is it better to assign an integer value (for example, 0 or -1) that cannot match the actual value in db:

 if (BookID > 0) {

EDIT: For further clarification, suppose I only want to return the book ID, not the entire book object. In db, the primary key is not NULL, but if I had to query for BookID "my book title", which was not there, then I would not get any results. Should this display as null?

Example:

 BookID = GetBookID("my book title");
+4
source share
5 answers

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

UPDATE

In order to query the database and find a suitable record, several solutions. I prefer to throw an exception because it usually indicates 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 usually can’t do anything else

  • throws an exception, which can be better done in GetById() (in addition, the caller may have more contextual information about the exception)
  • returns immidiatly with a zero code or an error code that requires processing by the caller, but this effectively rethinks the exception handling system.

If this is absolutely true, not finding a suitable entry, I suggest using the TryGet template.

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

I believe this is better than returning null, because null is a kind of magic value, and I don't like to see implementation details (the link type or the NULL value type can take a special value called null) in business logic. The disadvantage is that you lose compositional ability - you can no longer write Book.GetById(id).Order(100, supplier) .

The composition is backward below, but it has a very big problem - the book can be deleted between calling Exists() and GetById() , so I highly recommend not to use this template.

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

I prefer using a nullable int - this more directly matches what really will be in the database.

In addition, there are many times when there are no corresponding values ​​for a zero value. Using -1 to indicate null is bad practice, IMO, since -1 is often a valid value in the database.

+8
source

The primary key in Db is usually not NULL, and none of them should have a value in your program in most situations. But there are situations, such as the Find () function, which may require you to specify not found, and then you can use a value with a zero value. And when you go through the Find result form. How:

 int? foundBookID = FindBook(title); if (foundBookID.HasValue) { int BookID = foundBookID.Value; // not nullable ... }
+2
source

IMHO is 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 method is readable, provides basic type checking, allows two invariants (assigned identifier and not assigned) and is safe for throwing NullRerenceException.

0
source

Sounds like a loaded question. The way you requested it, yes, of course, uses the nullable int value. An exception that I can think of is if there is a lot of existing code that already uses / checks against 0 to represent not found. In this case, a sequence may be preferred. Zero types are relatively new, so looking at 0 is not unusual.

0
source

More articles:


All Articles