Mark D Wolinski wrote:
> >>- My question is that I defined the column access as INT (which can
> >>- be NULL),
> >>- however, when the statement runs, access isn't updated. It's not
> >>- necessarily a problem as I can go back and define the necessary columns
> as
> >>- NOT NULL, but is this the proper way the system should handle it.
> >>- It seems
> >>- to me that if you're adding one (or whatever) to the column if it's
> either
> >>- zero or NULL it should become what I was adding to it.
> >>
> >>Does it update when the value you're adding to is not NULL?
> >>
> >>NULL is just that -- nothing. It isn't a number, so you can't add to it.
> >>Any operation carried out on a NULL results in a NULL. If you wanted a
> >>number to represent 'no access yet', that sounds like zero to me.
>
> It does work fine when the column is not null.
>
> While I understand that NULL is not a number, the definition of the column
> as INT defines that column as holding numerical values. My argument is that
> in a self increment roll, the column should take the value of the increment
> if it is NULL or add it to its previous value if NOT NULL.
>
> The alternative is, if we want the ability to have a NULL column is to first
> check to see if it's null, then if it isn't self increment it, if it is set
> it to the increment already.
>
> I'm not implying that mySQL is broke. I'm just questioning the logic behind
> the action in this one instance.
>
> My project is still in development so it does me no harm to change my
> columns to NOT NULL.
>
--- snip ---
NULL, for a numeric column, represents an UNKNOWN value. If you add 1 to an
unknown value,
what is its's value? It probably is not "1".
It is still UNKNOWN, or NULL.
So, you see, it is not broken.
