DaFrizller:

FWIW, I agree strongly w/ Knut: this is not merely a storage issue but
a design issue. As you may be aware, the whole NULL/2VL/3VL issue is
very prickly, and pros and cons for both allowing and disallowing NULLs
abound (flip over to comp.databases.theory if you'd like to read some
spittle-flecked rants on the subject). The issue is not merely bytes
but also of semantics.

OK--enough soapboxing. You asked about Hibernate. One issue I'm aware
of is that it's not enough to declare a DEFAULT in DB2; you must also
declare the (same) default value in the BO (.java file). If you do not,
you risk overwriting the database-written default with whatever value
is in the instance variable mapped to the database field (often NULL),
when the Java values are persisted.

--Jeff

Knut Stolze wrote:
> DaFrizzler wrote:
>
> > Hi, I have received the following email from a colleague, and am quite
> > frankly baffled by the idea.
> >
> > I am just wondering if anyone has any advice or suggestions about
> > this????
> >
> >
> > === BEGIN MAIL ===
> > The DB2 DBA has requested that all columns in the tables be defined as
> > not null with default to improve storage, performance, and ease of
> > backup/recovery. Currently there are several columns in each table
> > that are nullable. By making these columns not null with default,
> > there would always be a value in the column, space for char/varchar,
> > and 0 for integer/smallint/decimal. Does this cause any problems with
> > the Java/Hibernate code? The DBA has indicated that all of the other
> > Java applications are defined this way.
> > === END MAIL ===
>
> Mark and Serge already gave some arguments. I think, there are a few more
> things to consider:
> (1) If you get rid of the null indicators by always using NOT NULL, you save
> some space (1 byte per row). However, each row where you would have a
> NULL before will now _waste_ space because the actual value has to be
> stored. Granted, default compression would reduce that again.
> (2) I don't think that decisions like nullable/not-nullable should be left
> to the DBA.
> It is a design decision during application development. The application
> developer are the only ones that know whether a nullable column makes
> sense or is mandatory in certain situations.
> As you already pointed out, there are sometimes no good defaults. Using
> 0 (zero) for numeric fields to represent NULL has a high chance of
> clashing with the numerical 0.
>
> --
> Knut Stolze
> DB2 z/OS Utilities Development
> IBM Germany