.NET: ¿Permitir NULLS en los campos DB?

Question

Tengo la tarea de volver a factorizar un SQLServer DB .... Muchas de las tablas y columnas "PERMITIR NULLS", ¿Es esta una buena práctica ...

Me parece recordar el authour de CSLA.NET diciendo que era una mala práctica permitir nulos en una base de datos ...

Si este es el caso, ¿cuáles son mis alternativas?

Quite todos los "NULOS PERMITIDOS" de todas las columnas .... y en columnas numéricas use un valor de -1 por ejemplo ??

Realmente agradecería cualquier aporte que alguien tenga.

Actualmente estoy usando un modelo (desde entidad marco) de mi DB y las columnas db que "PERMITIR NULLS" son nulas ... y algunos de los procedimientos almacenados requieren que tenga un valor predeterminado ... es decir, BOOLEAN requiere FALSE como predeterminado ... pero es nulo ..

Bueno, no quiero desviarme de mi pregunta original, PERMITIR NULLS es una mala cosa de lo que puedo reunir ... así que ¿cómo puedo solucionarlo? esta ?

Cualquier ayuda muy apreciada

Answer 1

nulo es a veces un valor de columna válido, pero sugeriría que una mejor práctica sería añadir en su lugar los valores por defecto y hacer que la columna no nula.

Si tiene datos existentes a considerar que tendría que hacer una actualización como:

update TableA set ColumnA = 'default value' where ColumnA is null 

... si quieres imponer 'no nulo' en los datos existentes.

Si no hay un valor por defecto razonable, entonces null puede ser un valor de columna perfectamente válido, pero a menudo existe un valor por defecto decente disponible.

Answer 2

NULLs son una plaga en la cara de la humanidad que debe ser erradicada de la existencia. Desafortunadamente, sin embargo, los sistemas e idiomas actuales (especialmente SQL) no están a la altura de la tarea de acomodar una revisión tan radical del pensamiento actual. De hecho, SQL es un gran perpetrador de esta parodia.

En el mundo real, por lo tanto, el consejo que daría es evitar NULL tanto como sea posible, pero acepto la realidad de que a veces no hay una alternativa fácil.

Answer 3

No hay duda de que los NULL deben evitarse cuando sea posible, debido a los problemas que pueden presentar varios problemas con la sintaxis de indexación y consulta.

Debido a los problemas que pueden presentar los NULL, ha habido un impulso para dejar de usarlos. Sin embargo, como la mayoría de estos movimientos, se ha salido de control, hasta el punto de que algunas personas insisten fanáticamente en que los NULL nunca se deben usar en la base de datos. Estuve en este campo durante muchos años, antes de encontrarme un poco demasiado entusiasta.

La respuesta está en algún punto intermedio. Los NULL deben evitarse siempre que sea posible, pero existen razones comerciales válidas para almacenarlos.

Muchas veces necesita almacenar un valor numérico opcional, y muchas personas le dirán que simplemente almacene un cero para indicar "sin valor", pero este es un antipatón aún peor de almacenar un valor mágico que realmente significa algo más .¿Qué pasa si no puedes usar cero para un campo, porque cero también se considera un valor significativo, o porque este valor se usa como el múltiplo de un divisor, entonces necesitas usar algún otro valor mágico (-1?) para ese campo en este caso, y ahora tiene un problema peor, porque todos sus campos numéricos opcionales ahora se comportan de manera diferente. Oye.

Las fechas son un candidato aún más convincente para los campos que aceptan valores numéricos. El estándar "sin valor" que las personas usan en .NET es el valor DateTime sin asignar predeterminado, que es DateTime.MinValue, o más específicamente el 1 de enero de 0001. Sin embargo, no puede escribir este valor mágico en la base de datos SQL porque el valor mínimo predeterminado un campo SQL Server DATETIME es el 1 de enero de 1973. Ahora debe tener algo que compruebe que está traduciendo esos valores correctamente a medida que se escriben y leen en la base de datos, y debe tener una codificación defensiva en todo el lugar que verifique para si sus campos de fecha son menores que SqlDateTime.MinValue, o simplemente para comprobar si son iguales a DateTime.MinValue. Double Oye.

Mi preferencia es tratar con los valores como realmente son, y no construir muchos constructos artificiales para ocultar el verdadero significado y uso del campo. Si un campo bien puede no tener un valor, hágalo aceptar el nulo y haga que se pueda agregar un nulo en los objetos de su aplicación (si su lenguaje admite tal cosa). Luego, cada vez que esté usando ese campo, debe considerar lo que debe hacerse en caso de que sea NULO, pero eso es realmente algo bueno. Por lo general, me opongo a que los desarrolladores desperdicien sus conocimientos sobre la complejidad innecesaria del código, pero eso se debe a que le quita el enfoque al verdadero problema comercial que se está resolviendo; sin embargo, en este caso, la falta de un valor ES parte del verdadero problema comercial y debe ser pensado. Si solo está incumpliendo este valor, el desarrollador que escriba una fórmula o algoritmo tendrá menos probabilidades de pensar en esas condiciones de borde donde faltan los valores, y puede que ni siquiera se dé cuenta en el momento en que existe la posibilidad de que esos valores falten. .

Answer 4

El uso de un valor nulo es un caso donde la desnormalización leve puede traer un gran beneficio de rendimiento. En el mundo real, un valor NULL es una forma perfectamente válida de decir que no se ha registrado un valor . Esto es especialmente relevante para valores booleanos (BIT) y valores numéricos opcionales.

Los puristas harán que cree una nueva tabla con una combinación izquierda para registrar este valor. El realista alterará la tabla existente y agregará un valor nulo.

Definitivamente hay casos en que los nulos son relevantes. El genérico Nullable se agregó al .NET framework para los tipos de valor por exactamente el mismo motivo.