views:

312

answers:

5

Hello,

I'm curious to know how NULLs are stored into a database ?

It surely depends on the database server but I would like to have an general idea about it.


First try:

Suppose that the server put a undefined value (could be anything) into the field for a NULL value.

Could you be very lucky and retrieve the NULL value with

...WHERE field = 'the undefined value (remember, could be anything...)'


Second try:

Does the server have a flag or any meta-data somewhere to indicate this field is NULL ?

Then the server must read this meta data to verify the field.

If the meta-data indicates a NULL value and if the query doesn't have "field IS NULL", then the record is ignored.


It seems too easy...

+2  A: 

The server typically uses meta information rather than a magic value. So there's a bit off someplace that specifies whether the field is null.

Adam Davis
+9  A: 

MySql uses the second method. It stores an array of bits (one per column) with the data for each row to indicate which columns are null and then leaves the data for that field blank. I'm pretty sure this is true for all other databases as well.

The problem with the first method is, are you sure that whatever value you select for your data won't show up as valid data? For some values (like dates, or floating point numbers) this is true. For others (like integers) this is false.

Thomas Jones-Low
+1  A: 

On PostgreSQL, it uses an optional bitmap with one bit per column (0 is null, 1 is not null). If the bitmap is not present, all columns are not null.

This is completely separate from the storage of the data itself, but is on the same page as the row (so both the row and the bitmap are read together).

References:

CesarB
+1  A: 

IBM Informix Dynamic Server uses special values to indicate nulls. For example, the valid range of values for a SMALLINT (16-bit, signed) is -32767..+32767. The other value, -32768, is reserved to indicate NULL. Similarly for INTEGER (4-byte, signed) and BIGINT (8-byte, signed). For other types, it uses other special representations (for example, all bits 1 for SQL FLOAT and SMALLFLOAT - aka C double and float, respectively). This means that it doesn't have to use extra space.

IBM DB2 for Linux, Unix, Windows uses extra bytes to store the null indicators; AFAIK, it uses a separate byte for each nullable field, but I could be wrong on that detail.

So, as was pointed out, the mechanisms differ depending on the DBMS.

Jonathan Leffler
+1  A: 

The problem with special values to indicate NULL is that sooner or later that special value will be inserted. For example, it will be inserted into a table specifying the special NULL indicators for different database servers

| DBServer     | SpecialValue |
+--------------+--------------+
| 'Oracle'     | 'Glyph'      |
| 'SQL Server' | 'Redmond'    |

;-)

Bjarke Ebert