Crear una tabla db Prácticas recomendadas NULL

Question

No estoy seguro de cuáles son las mejores prácticas para tratar con valores NULL cuando tengo una sola tabla donde dos campos solo se rellenan algunas veces creando muchos valores NULL en las filas.

¿Deberían los dos campos moverse a una tabla separada creando dos tablas sin valores NULOS?

Unir estas dos tablas simplemente devolvería un resultado que iguala mi tabla original con las NULL, entonces, ¿qué sentido tiene eso?

Parece inútil separarlos, pero he estado leyendo un poco acerca de evitar que los nulos estén todos juntos en la base de datos.

Cualquier idea bienvenida.

Answer 1

1. Teóricamente, se supone que un NULL significa "valor desconocido". Por lo tanto, de nuevo, puramente teóricamente, debe diseñar sus tablas cuando esté normalizado para que no tenga que completar valores NULOS para indicar "no aplicable para esta fila". Sin embargo, este punto no tiene ninguna relación con ninguna consideración práctica (diseño, rendimiento o legibilidad de consultas).

2. Prácticamente, hay algunas consideraciones de rendimiento. Usted debe normalizar los datos de distancia muy escasa en los siguientes casos:

   • hay beneficio material de acortar la mesa (IO tanto sabia y/o en el espacio del reloj). Los NULL ocupan espacio, y cuanto más anchas sean las filas, peor será el rendimiento. Esto es especialmente cierto cuando la tabla tiene MUCHAS filas y hay muchas columnas dispersas. Para una tabla más pequeña con solo 2 de tales columnas, los beneficios obtenidos podrían no valer la pena de tener una unión extra.

   • Sus consultas tienen la columna en cuestión en la cláusula WHERE. IIRC, consultar en una columna fuertemente NULL-ed es bastante ineficiente.

   • Por otro lado, en cierto punto, tener uniones adicionales en la consulta puede perjudicar el rendimiento del optimizador (al menos lo hace en Sybase una vez que sus uniones tienen más de 10 tablas, desde ocupar recursos de la CPU cuando el optimizador se ejecuta realmente confundiendo el optimizador para elegir un plan MUY malo). La solución es evitar tener demasiadas tablas debido a la normalización (como en, no molestar en dividir sus 2 columnas en una tabla separada), o forzar el plan de consulta. El último es obviamente Bad Juju.

Answer 2

Nulos causan resultados incorrectos e inconsistentes en las consultas y en general aumentan la complejidad del código debido al manejo especial que se necesita en el código que tiene que procesarlos. Por estas razones, generalmente tiene sentido evitar o minimizar los nulos en los diseños de su base de datos. Tampoco necesita usar nulos en las consultas, aunque SQL lamentablemente los hace muy difíciles de evitar. Sin embargo, al no usar valores nulos en las tablas base, se asegurará de que su modelo de datos refleje con mayor precisión la realidad y le dará a los usuarios de la base de datos más control sobre cómo desean que se utilicen los nulos.

Answer 3

Como dportas implica en un comentario, es útil saber qué es un valor null en un campo particular significa - no es lo que significa en teoría, pero lo que significa en sus datos.

pienso todo el tiempo que esté claro lo que significa un null en su mesa, y si está seguro de que sólo significa una cosa , se puede tomar una decisión informada sobre si pragmática para permitirlo.

Opinión: Mi regla de oro es que los campos anulables están bien, pero no deben realizar varias tareas

Answer 4

valores nulos son fundamentales para tener en una base de datos. Nunca he tratado con una base de datos que no permitiera nulos que al final no fue mucho más difícil de consultar, mucho más difícil de mantener (cómo se decide qué valor significa que no sé la respuesta) y generalmente tengo más datos malos Sí nulos requieren un manejo especial en las consultas, por lo que hacer cosas como agregar una fecha posterior (1/1/9999) como fecha de finalización para evitar tener un nulo.

La verdad es que algunos datos simplemente no se conocen en el momento en que se inserta el registro. No hay sustituto para nulo.

Ahora en su caso, si debe dividirse en dos tablas depende mucho del ancho de las tablas y la frecuencia que necesitará para consultar esas columnas que aceptan valores nulos. No es probable que mueva una columna de segundo plano a otra tabla, aunque tuve muchos nulos porque siempre se consulta con la otra información en la tabla base. También es poco probable que mueva una columna de fecha de finalización. Pero si las columnas son cosas que es bueno conocer pero que normalmente no se consultan cada vez que consulta los datos base (como Cumpleaños, color de cabello, etc.), entonces una tabla de referencia solo para los registros que contienen los datos puede estar bien. Sin embargo, recuerde que cuando consulta si usa una combinación interna, elimina todos los registros que no tienen un valor en la segunda tabla. Si normalmente quisiera todos los registros (como con el segundo nombre, raramente consulto solo para encontrar a las personas con un segundo nombre de 'Mary'), entonces tiendo a mantenerlos en la misma tabla a menos que la mesa esté muy amplia y yo Por lo general, no quiero consultar esa información.