Algunas personas intentan evitar NULL valores, alegando que la lógica sería confusa.
No soy uno de ellos. NULL los valores están bien para columnas sin datos. Sin duda, son la forma más económica de almacenar columnas "vacías", tanto para el espacio en disco como para el rendimiento (el efecto principal son tablas e índices más pequeños):
- ¿No usar NULL en PostgreSQL todavía usa un mapa de bits NULL en el encabezado?
- ¿La configuración de "NO NULO" en una columna en postgresql aumenta el rendimiento?
- ¿Las columnas anulables ocupan espacio adicional? en PostgreSQL?
Una vez que comprendes la naturaleza de NULL valores, no hay razón para evitarlos. Postgres ofrece una variedad de funciones para tratar con NULL. colaesce()
, nullif()
, concat() , concat_ws()
, ...
En general, en cuanto al rendimiento se refiere, una restricción NOT NULL supera una restricción CHECK y ambos vencieron a triggers por un tiro de registro. Pero incluso los disparadores simples son baratos. El costo de un NOT NULL la restricción es casi nada. Además, todo esto solo afecta las operaciones de escritura, pero en la mayoría de las aplicaciones dominan las operaciones de lectura.
El impacto más relevante en el rendimiento (aparte de las consultas y los índices subóptimos), por lo tanto, es el tamaño. de tablas e índices o, lo que es más importante, el número de tuplas por página de datos . Las tuplas más grandes conducen a un rendimiento más lento para la mayoría de los casos de uso. El número de páginas de datos que deben leerse para satisfacer una consulta aumenta en consecuencia. La memoria caché disponible se satura antes.
No tengo un punto de referencia listo, pero de todos modos es mejor probar para su entorno particular. Estas son solo reglas generales simples. La realidad es mucho más compleja.
