76 votos

El uso estándar de la 'Z' en lugar de NULL para representar los datos que faltan?

Fuera de la discusión de si es o no valores Nulos debe ser usado alguna vez: yo soy el responsable de una base de datos existente que utiliza NULL significa "falta o no se introducen datos". Es diferente de la cadena vacía, que significa "un conjunto de usuarios de este valor, y que la selección 'vacío'."

De otro contratista en el proyecto está firmemente en el "valores Nulos no existe para mí; yo nunca uso NULO y nadie más debe, ya sea en el" lado de la discusión. Sin embargo, lo que me confunde es que desde que el equipo del contratista reconoce la diferencia entre "missing/nunca entró" y "intencionalmente vacía o indicado por el usuario como desconocido," utilizan un único carácter 'Z' a lo largo de su código y de los procedimientos almacenados para representar a los "desaparecidos/nunca entró" con el mismo significado como NULO en el resto de la base de datos.

Aunque compartimos el cliente ha solicitado para cambiar esto, y me han apoyado esta petición, el equipo de la cites esto como una "práctica estándar" entre los Administradores de bases de datos mucho más avanzados que yo, son reacios a cambiar el uso de valores Nulos basado en mi ignorante solicitud solos. Así que, ¿alguien puede ayudarme a superar mi ignorancia? ¿Hay alguna norma, o pequeño grupo de individuos, o incluso una sola voz alta entre SQL expertos, que aboga por el uso de " Z " en lugar de NULL?

Actualización

Tengo una respuesta por parte de el contratista a agregar. Esto es lo que dijo cuando el cliente pide para los valores especiales que ser eliminado para permitir valores NULL en las columnas con ninguna de datos:

Básicamente, he diseñado la base de datos para evitar valores Nulos siempre que sea posible. Aquí está la razón:

Un valor NULL en una cadena de texto [VARCHAR] campo nunca es necesaria debido a un vacío (de longitud cero) cadena proporciona exactamente la misma información.

Un valor NULO en un campo de número entero (por ejemplo, un valor de ID) puede ser manejado mediante el uso de un valor que nunca iba a ocurrir en los datos (e.g, -1 para el entero campo de IDENTIDAD).

Un valor NULO en un campo de fecha que fácilmente puede causar complicaciones en los cálculos de fecha. Por ejemplo, en la lógica que calcula la fecha de diferencias, tales como la diferencia en días entre un [RecoveryDate] y un [OnsetDate], la lógica va a explotar si una o ambas fechas son NULOS, a no ser que explícitamente se contemplan ambas fechas se va a NULL. Eso es trabajo extra y un manejo adicional. Si por "defecto" o "marcador de posición", las fechas que se usan para [RecoveryDate] y [OnsetDate] (por ejemplo, "1/1/1900") , cálculos matemáticos podría mostrar "inusual" valores -, pero la fecha de la lógica de no volar.

NULO manejo ha sido tradicionalmente un área donde los desarrolladores de cometer errores en los procedimientos almacenados.

En mis 15 años como DBA, he encontrado que es mejor evitar valores Nulos siempre que sea posible.

Esto parece validar la mayoría de la reacción negativa a esta pregunta. En lugar de aplicar una aceptadas 6NF enfoque para el diseño de valores Nulos, valores especiales son usados para "evitar valores Nulos siempre que sea posible." He publicado este tema con una mente abierta, y me alegro de haber aprendido más acerca de los "valores Nulos son útiles / Nulos son malos" debate, pero ahora estoy bastante cómodo etiquetado de los 'valores especiales' enfoque de ser una completa tontería.

un vacío (de longitud cero) cadena proporciona exactamente la misma información.

No, no; en la base de datos existente estamos modificando, NULL significa "nunca entró" y la cadena vacía significa "entró como vacío".

NULO manejo ha sido tradicionalmente un área donde los desarrolladores de cometer errores en los procedimientos almacenados.

Sí, pero esos errores se han hecho miles de veces por miles de desarrolladores, y las lecciones y advertencias para evitar esos errores son conocidos y documentados. Como ha sido mencionado aquí: si usted acepta o rechaza los Nulos, la representación de los valores perdidos es un problema resuelto. No hay necesidad de inventar una nueva solución, ya que los desarrolladores continuar hacen fácil de superar (y fáciles de identificar) los errores.


Como una nota al pie: he sido un DBE y desarrollador por más de 20 años (que sin duda es el tiempo suficiente para mí saber la diferencia entre una base de datos ingeniero y administrador de base de datos). A lo largo de mi carrera he sido siempre en los "valores Nulos son útiles camp", a pesar de que yo era consciente de que varias personas muy inteligentes no estuvieron de acuerdo. Yo era muy escéptico acerca de los "valores especiales", pero no lo suficientemente versado en los académicos de "Cómo Evitar NULO el Camino Correcto" para hacer un soporte firme. Siempre me encanta aprender cosas nuevas-y todavía tengo mucho que aprender después de 20 años. Gracias a todos los que contribuyeron a hacer de este un debate útil.

104voto

MatBailie Puntos 37610

Saco de su contratista.

Bueno, en serio, esto no es una práctica estándar. Esto puede ser visto simplemente porque todos los RDBMS que he trabajado con implementar NULL, lógica NULL, NULL en el extranjero, claves, tiene un comportamiento distinto de NULL en el CONTEO, etc, etc.

Me gustaría realmente sostienen que el uso de la 'Z' o cualquier otro lugar del titular es peor. Todavía requiere código de verificación para la 'Z'. Pero también es necesario que el documento que la 'Z' no significa 'Z', que significa algo más. Y usted tiene que asegurarse de que la documentación que se lee. Y entonces, ¿qué sucede si la 'Z' alguna vez se convierte en una pieza válida de datos? (Como un campo para la inicial?)

En un nivel básico, incluso sin debatir la validez de NULL vs 'Z', me gustaría insistir en que el contratista se ajusta a las prácticas estándar que existen dentro de su empresa, no de él. Instituir su práctica estándar en un entorno con una alternativa práctica estándar causará confusión, mantenimiento, gastos generales, malentendidos, y en la final el incremento de costos y errores.


EDITAR

Hay casos donde el uso de una alternativa a NULL es válido en mi opinión. Pero sólo cuando así se reduce el código, en lugar de crear casos especiales que requieren de contabilidad.

He usado que para la fecha de enlazado de datos, por ejemplo. Si los datos son válidos entre una fecha de inicio y una fecha de fin, el código puede ser simplificado por no tener valores NULL. En lugar de un valor NULO de la fecha de inicio podría ser sustituido por '01 Jan, 1900' y un valor NULL fecha final podría ser la sustitución del 31 Dic 2079'.

Esto aún puede cambiar el comportamiento de lo que se podría esperar, y por lo que debe usarse con cuidado:

  • WHERE end-date IS NULL no dar datos que aún es válido
  • Usted acaba de crear su propia millennium bug
  • etc.

Esto es equivalente a la reforma de las abstracciones de tal manera que todas las propiedades tienen valores válidos. Es marcadamente diferente de forma implícita la codificación significado específico en arbitrariamente valores elegidos.

Aún así, saco el contratista.

26voto

Mark Mann Puntos 2872

Esto es fácilmente uno de los más extraños de las opiniones que he escuchado. El uso de una magia valor para representar "sin datos" en lugar de NULL significa que cada pieza de código que usted tiene para el post-proceso de los resultados de la cuenta/descartar el "sin datos"/"Z" de los valores.

NULL es especial porque de la manera que la base de datos se encarga de las consultas. Por ejemplo, tomemos a estas dos simples preguntas:

select * from mytable where name = 'bob';
select * from mytable where name != 'bob';

Si name es siempre NULO, es obvio que no aparezca en los primeros resultados de la consulta. Lo que es más importante, ni va a aparecer en la segunda de las consultas de resultados. NULL no coincide con otra cosa que una búsqueda explícita de NULO, como en:

select * from mytable where name is NULL;

Y lo que sucede cuando los datos podían haber Z como un valor válido? Digamos que usted está almacenando alguien inicial? Sería Zachary Z Zonkas se mezclen con los de las personas sin inicial? O su contratista venido con otra magia valor a manejar esto?

Evitar la magia de los valores que se requieren para implementar características de base de datos en el código que la base de datos ya está totalmente capaz de manejar. Este es un resuelto y se entiende bien el problema, y que sólo puede ser que el contratista nunca realmente grokked la noción de NULO y por lo tanto evita el uso de la misma.

22voto

Mitch Wheat Puntos 169614

Si el dominio permite a los valores que faltan, a continuación, utilizar un valor NULL para representar " indefinido " es perfectamente CORRECTO (que es lo que hay). El único inconveniente es que el código que consume los datos tiene que ser escrito para comprobar los valores Null. Esta es la manera que yo siempre lo he hecho.

Nunca he oído hablar de (o visto en la práctica) el uso de la 'Z' para representar los datos que faltan. En cuanto a "el contratista de la cites como " práctica estándar " entre los Administradores de bases de datos", puede proporcionar alguna evidencia de esta afirmación? Como @Dems mencionado, también se deben documentar que la 'Z' no significa 'Z': ¿qué MiddleInitial columna?

Como Aarón Alton y muchos otros, creo que los valores NULL son una parte integral de diseño de base de datos, y deben ser utilizados cuando proceda.

17voto

WW. Puntos 11335

Incluso si de alguna manera se las arreglan para explicar a todos sus actuales y futuros desarrolladores y Administradores de bases de datos acerca de la "Z" en lugar de NULL, e incluso si el código de todo a la perfección, usted todavía va a confundir el optimizador porque no va a saber que has cocinado.

El uso de un valor especial para representar un valor NULL (el cual es ya un valor especial para representar NULL) dará lugar a sesgos en los datos. por ejemplo, muchas cosas sucedieron en 1-Ene-1900, que se va a tirar el optimizador de la capacidad de entender que el rango de fechas que realmente son relevantes para su aplicación.

Esto es como un gerente de decidir: "se Llevaba un empate es malo para la productividad, por lo que todos vamos a usar cinta de enmascarar alrededor de nuestros cuellos. Problema resuelto."

9voto

stakx Puntos 29832

Nunca he escuchado sobre el uso extendido de 'Z' como un sustituto para NULL.

(Por cierto, no me había gusta especialmente trabajar con un contratista que le dice en la cara que ellos y otros "avanzado" Administradores de bases de datos son mucho más conocimiento y mejor que usted.)

 +=================================+
 |  FavoriteLetters                |
 +=================================+
 |  Person      |  FavoriteLetter  |
 +--------------+------------------+
 |  'Anna'      |  'A'             |
 |  'Bob'       |  'B'             |
 |  'Claire'    |  'C'             |
 |  'Zaphod'    |  'Z'             |
 +---------------------------------+

¿Cómo sería su contratista de interpretar los datos de la última fila?

Probablemente iba a escoger una de las diferentes "magia valor" en esta tabla, para evitar la colisión con los datos reales 'Z'? Lo que significa que tendría que recordar varias magia de valores, y también cuál es el utilizado en las que... ¿cómo es esto mejor que tener sólo una magia token NULL, y tener que recordar los tres valores de las reglas de lógica (y trampas) que se vaya con él? NULL , al menos, está estandarizado, a diferencia de la del contratista, 'Z'.

No me gustan NULL , pero sin sustituirlo con un valor real (o peor, con varios valores reales) en todas partes , es casi seguro que peor que NULL.

Permítanme repetir mi comentario de arriba aquí para una mejor visibilidad: Si quieres leer algo serio y bien fundamentado por las personas que están en contra de NULL, yo recomendaría el breve artículo "Cómo manejar la falta de información sin el uso de valores Nulos" (enlaces a un archivo PDF desde El Tercer Manifiesto de la página de inicio).

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by: