Tipos de datos varchar anulables frente a no nulos: ¿qué es más rápido para las consultas?

Question

Por lo general, preferimos tener todas nuestras columnas varchar/nvarcharque no admiten nulos con una cadena vacía ('') como valor predeterminado. Alguien en el equipo sugirió que anulable es mejor porque:

Una consulta como esta:

Select * From MyTable Where MyColumn IS NOT NULL 

es más rápido que esto:

Select * From MyTable Where MyColumn == '' 

Alguien tiene alguna experiencia para validar si se trata de ¿cierto?

Answer 1

En algunas plataformas (e incluso versiones), esto dependerá de cómo se indexan los NULL.

Mi regla básica para los valores NULL es:

1. No permita que los nulos hasta que justifica

2. No permita que los valores NULL a menos que los datos pueden ser muy desconocida

Un buen ejemplo de esto es el modelado de líneas de dirección. Si tiene una AddressLine1 y una AddressLine2, ¿qué significa que el primero tenga datos y el segundo que sea NULL? Me parece a mí, o bien sabes la dirección o no, y tener NULL parciales en un conjunto de datos solo pide problemas cuando alguien los concatena y obtiene NULL (comportamiento ANSI). Puede resolver esto permitiendo valores NULL y agregando una restricción de verificación: o bien toda la información de Dirección es NULA o no lo es.

Algo similar con la inicial del segundo nombre. Algunas personas no tienen una. ¿Es esto diferente de ser desconocido y te importa?

También, fecha de la muerte, ¿qué significa NULL? ¿No muerto? Fecha desconocida de la muerte? Muchas veces una sola columna no es suficiente para codificar el conocimiento en un dominio.

Así que para mí, si se debe permitir valores NULL dependería en gran medida de las semántica de los primeros de los datos - el rendimiento va a ser segundo, porque después de haber mal interpretado los datos (potencialmente por muchas personas diferentes) es por lo general un mucho más caro problema que el rendimiento.

Puede parecer una cosita (en SQL Server, la implementación es una máscara de bits almacenada con la fila), pero me parece que funcionar solo mejor que NULL después de la justificación. Capta las cosas al principio del desarrollo, te obliga a abordar las suposiciones y a comprender el dominio de tu problema.

Answer 2

Si desea saber que no hay ningún valor, use NULL.

En cuanto a la velocidad, IS NULL debe ser más rápido, ya que no utiliza la comparación de cadenas.

Answer 3

¡Dile a ese tipo en tu equipo que le saque la cabeza prematuramente de su culo! (Pero de una manera agradable).

Desarrolladores como este pueden envenenar al equipo, llenos de mitos de optimización de bajo nivel, todos los cuales pueden ser ciertos o verdaderos en algún momento específico para algún proveedor o patrón de consulta específico, o posiblemente solo verdaderos en teoría, pero nunca es cierto en la práctica.Actuar sobre estos mitos es una costosa pérdida de tiempo y puede destruir un diseño que de otra manera sería bueno.

Probablemente esté bien y quiera aportar su conocimiento al equipo. Desafortunadamente, él está equivocado. No está mal en el sentido de si un punto de referencia demostrará que su afirmación es correcta o incorrecta. Está equivocado en el sentido de que no es así como se diseña una base de datos. La cuestión de si hacer un campo NULL-able es una pregunta sobre el dominio de los datos a los efectos de definir el tipo de campo. Debe responderse en términos de lo que significa para el campo no tener ningún valor.

Answer 4

En pocas palabras, NULL = ¡DESCONOCIDO! ... Lo que significa (usando el ejemplo de fecha de la muerte) que la entidad podría estar 1) viva, 2) muerta, pero no se conoce la fecha de la muerte, o 3) desconocida si la entidad es vivo o muerto. Para las columnas numéricas, siempre las asigno por defecto a 0 (ZERO) porque en algún punto de la línea puede que tenga que realizar cálculos agregados y NULL + 123 = NULL. Para los alfanuméricos utilizo NULL ya que su rendimiento es más económico y es más fácil decir '... donde a IS NULL' que diciendo '... donde a = ""'. Usar '... donde a = "" [espacio]' no es una buena idea porque [espacio] no es NULO! Para las fechas, si tiene que dejar una columna de fecha NULA, puede agregar una columna de indicador de estado que, en el ejemplo anterior, A = Vivo, D = Muerto, Q = Muerto, fecha de muerte desconocida, N = Vivo o Muerto es desconocido.

Answer 5

Si necesita NULL, use NULL. Lo mismo ocurre con la cuerda vacía.

En cuanto a rendimiento, "depende"

Si tiene varchar, que está almacenando un valor real en la fila para la longitud. Si tiene char, entonces almacena la longitud real. NULL no se almacenará en filas según el motor (mapa de bits NULL para SQL Server, por ejemplo).

Esto significa que IS NULL es más rápido, consulta para consulta, pero podría agregar complejidad COALESCE/NULLIF/ISNULL.

Por lo tanto, su colega es parcialmente correcto, pero puede que no lo aprecie por completo.

A ciegas utilizando cadena vacía es el uso de un valor centinela en lugar de trabajar a través de la NULL cuestión semántica

Fwiw y personalmente:

• me habría tienden a utilizar NULL, pero no siempre . Me gusta evitar las fechas como el 31 de diciembre de 1999, que es donde la evitación NULL te guía.

• De la respuesta de Cade Roux ... También encuentro que las discusiones sobre "Es nullable la fecha de la muerte" no tienen sentido. Para un campo, en términos prácticos, o bien hay un valor o no existe.

• Los valores de Sentinel son peores que NULL. Números mágicos. ¿nadie?