On Nullable columns

Varchar columns can use a length of 0 to indicate lack of a value so there is no point in defining them as NULLABLE. Defining them as nullable adds an extra byte to the row in addition to the existing 2 bytes which denote the length of the varchar. Also, the check on 0 length can possibly circumvent all the controversy around equivalence or otherwise of '' and NULL. A small UDF may be called for in databases which say length(NULL) = NULL to instead return 0.

In Oracle, nulls are not stored in an index while in DB2 they are. If I have a unique index defined on a nullable column in Oracle, it will allow any number of nulls while enforcing uniqueness on the non-null values. In DB2, this won't happen by default unless the index is defined as being UNIQUE WHERE NOT NULL (supported on DB2 z/OS 9.1 but not LUW 9.5).

Index entries for NULL have their first byte set to X'FF' in DB2 and hence will be the rightmost value. When rows are being inserted in ascending order, if the last page is full and the new value is the highest in the index, DB2 does not split the last page but instead allocates a fresh new page. That way, leaf pages won't remain half empty. However, the presence of a single NULL value in the table can defeat this rule and lead to many half-empty pages.