Is there a situation where categoryID parameter could receive value smaller than zero

carewithl · October 6th, 2009, 01:26 PM

Hi,

Code:

      public static List<Article> GetArticles(int categoryID)
           {
            if ( categoryID <= 0 )
               return GetArticles();
           ...
     }

DLLâs GetArticles() method relies on primary key ( CategoryID ) of Category DB table always having a value equal or greater than 1. But as far as I know, primary keys could also be configured to accept zero as their value?!

a) So isnât GetArticles() flawed, since DB programmer (assuming DLL programmer wonât also create DAL layer and DB tables ) could in the future configure primary key of Category table to also accept value zero? In that case, GetArticles() will never return an article with ID = 0

b) Is there a situation, where categoryID parameter could receive a value smaller than zero? In not, then we could also write:

Code:

        public static List<Article> GetArticles(int categoryID)
        {
            if ( categoryID == 0)
               return GetArticles();
            ...
    }

thanx

Lee Dumond · October 6th, 2009, 03:03 PM

Primary keys can in fact accept ANY valid data type, including any integer. You could conceivably have a primary key value of -3827 if you wanted.

However, the indentity fields in the tables are set up such that they always start at one and increment by +1. That means that, in this case, we can rest assured that any category will always have an ID greater than zero.

What you are asking is this: Couldn't the DBA alter the table such that categoryIDs can be zero, or less than zero? Well, yes, they certainly could. That would obviously screw things up. But the fact is that once you start programming against a given database schema, any alteration to that schema is likely to screw things up. What if the DBA decided to change the name of a stored procedure? That would mess up an application programmer too, right? Because of this, if a DBA had some reason to go changing things, he would have an obligation to tell the programmers about it, so that they could change their code accordingly.

There's not much you can do about this. It's like programming against any API. A programmer has a right to expect that an API will honor its contract. In this case, the programmer expects category IDs to always be positive integers. If the API suddenly changes without notice, then you have to change things around on your end or you're in trouble.

As to your second question -- I do believe that would work. Because the methods that retrieve the articles actually get their value from ddlCategories.SelectedValue, and not from the CatID querystring value directly, any value that is not an existing categoryID will always be passed as zero anyway.

carewithl · October 6th, 2009, 03:59 PM

hi

So thereâs general consensus among programmers that primary keys should always have positive values?

cheers mate

Lee Dumond · October 6th, 2009, 04:05 PM

I suppose. When you count things, most people start at one and go up by ones. There's no rule that says integer primary keys have to work that way, but it just kinda makes sense.

The main cases where I've seen it work differently is when you expect to at some point have more records than be held by a positive 32 bit integer, in which case you might start from the smallest negative value and work up from there. This doubles the number of possible values you can have.

I generally tend to use GUIDs anyway, so it's not too much of an issue for me. ;)

carewithl · October 7th, 2009, 08:29 PM

thanx for your help :)

cheers mate