Pregunta

Tengo curiosidad por saber cómo se almacenan los NULL en una base de datos?

Seguramente depende del servidor de la base de datos, pero me gustaría tener una idea general al respecto.


Primer intento:

Supongamos que el servidor coloca un valor indefinido (podría ser cualquier cosa) en el campo para un valor NULO.

¿Podría ser muy afortunado y recuperar el valor NULL con

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

Segundo intento:

¿El servidor tiene una bandera o algún metadato en algún lugar para indicar que este campo es NULO?

Luego, el servidor debe leer estos metadatos para verificar el campo.

Si los metadatos indican un valor NULO y si la consulta no tiene el campo "ES NULO", entonces el registro se ignora.


Parece demasiado fácil ...

¿Fue útil?

Solución

En PostgreSQL, usa un mapa de bits opcional con un bit por columna (0 es nulo, 1 no es nulo). Si el mapa de bits no está presente, todas las columnas no son nulas.

Esto está completamente separado del almacenamiento de los datos en sí, pero está en la misma página que la fila (por lo tanto, tanto la fila como el mapa de bits se leen juntos).

Referencias:

Otros consejos

MySql usa el segundo método. Almacena una matriz de bits (uno por columna) con los datos de cada fila para indicar qué columnas son nulas y luego deja los datos para ese campo en blanco. Estoy bastante seguro de que esto es cierto para todas las demás bases de datos también.

El problema con el primer método es, ¿está seguro de que cualquier valor que seleccione para sus datos no se mostrará como datos válidos? Para algunos valores (como fechas, o números de punto flotante) esto es cierto. Para otros (como los enteros) esto es falso.

El servidor normalmente usa metainformación en lugar de un valor mágico. Así que hay un poco fuera de lugar que especifica si el campo es nulo.

-Adam

IBM Informix Dynamic Server utiliza valores especiales para indicar valores nulos. Por ejemplo, el rango válido de valores para un SMALLINT (16 bits, firmado) es -32767 .. + 32767. El otro valor, -32768, está reservado para indicar NULL. Del mismo modo para INTEGER (4 bytes, firmado) y BIGINT (8 bytes, firmado). Para otros tipos, usa otras representaciones especiales (por ejemplo, todos los bits 1 para SQL FLOAT y SMALLFLOAT, también conocido como C doble y flotante, respectivamente). Esto significa que no tiene que usar espacio extra.

IBM DB2 para Linux, Unix, Windows usa bytes adicionales para almacenar los indicadores nulos; AFAIK, usa un byte separado para cada campo anulable, pero podría estar equivocado en ese detalle.

Entonces, como se señaló, los mecanismos difieren según el DBMS.

El problema con los valores especiales para indicar NULL es que tarde o temprano se insertará ese valor especial. Por ejemplo, se insertará en una tabla que especifique los indicadores NULL especiales para diferentes servidores de bases de datos

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

;-)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top