Diseño de la base de datos - campos vacíos

Question

Actualmente estoy debatiendo un problema con mi equipo de desarrollo. Ellos creen que los campos vacíos son malas noticias. Por ejemplo, si tenemos una tabla de detalles del cliente que almacena datos para clientes de diferentes países, y cada país tiene una configuración de dirección ligeramente diferente, más 1-2 campos adicionales, p. Los detalles del cliente francés también pueden almacenar detalles para el código de entrada, y los campos de piso/nivel más título (madamme, etc.). Sudáfrica tendría un número de seguridad. Y así.

Dado que estamos hablando de pequeñas variaciones, mi idea es incluir todos los campos en la tabla y usar lo que se necesita en cada formulario.

Mi colega cree que deberíamos tener una tabla separada con datos adicionales. P.ej. customer_info_fr. Pero esto parece frustrar totalmente el propósito de una mesa combinada en primer lugar.

El argumento es que los campos/columnas vacíos son malos, pero me cuesta encontrar la justificación en términos de principios de diseño de bases de datos a favor o en contra de este argumento y las soluciones preferidas.

Otra opción es una mini tabla EAV separada que almacena datos adicionales con parent_id, key, val fields. O para serializar datos adicionales en una columna extra_data en la tabla principal customer_data.

Creo que estoy confundido porque lo que estoy discutiendo no está cubierto por 3NF, que es lo que normalmente usaría como referencia sobre cómo estructurar los datos.

Así que mi pregunta en concreto: -

Si usted tiene pequeñas variaciones en los datos para cada registro (1-2 campos diferentes, por ejemplo) ¿cuál es la mejor manera de proceder?

Answer 1

Los nulos invariablemente agregan complejidad a un modelo de datos porque el comportamiento de nulo en SQL raramente coincide con las matemáticas, la lógica o la realidad que pretendía modelar con él. En otras palabras, algunas consultas arrojan resultados incorrectos, que luego debe compensar con una lógica adicional.

Toda la información se puede representar con exactitud sin nulos. Como los nulos agregan complejidad, es una práctica de diseño de sonido comenzar su modelo de datos sin ellos y luego solo agregar un valor nulo donde encuentre alguna razón especial para hacerlo o donde alguna característica o limitación de la base de datos le obligue a anular.

Answer 2

Para eso son los campos anulables: "Datos no disponibles/aplicables".

SQL tiene una noción diferente de nulo que la mayoría de los lenguajes de programación, por lo que el nulo de SQL a menudo es un concepto incomprendido.

Answer 3

Me interesaría la justificación de tu colega de por qué los campos vacíos son malos. Por lo que yo sé, campos vacíos o nulos no son malos en sí mismos. Si tiene muchos valores de datos vacíos para una columna en la que planea colocar un índice importante, es posible que desee considerar otras opciones. Esto se aplica a cualquier columna en la que tenga muchos registros duplicados y necesite un índice, como registros duplicados lower the cardinality de la columna, lo que hace que los índices sean menos útiles. En tu caso, no veo que sea un problema.

Para este tipo de datos, es probable que utilice un VARCHAR o algún tipo de columna de TEXTO de todos modos, que son campos de longitud variable en la base de datos. No importa si su campo está lleno de datos o está vacío, todavía incurrirá en la sobrecarga de una columna de longitud variable (que no vale la pena preocuparse en circunstancias normales). Entonces, de nuevo, no hay diferencia con el RDBMS.

Según los sonidos de lo que está diseñando, creo que si se llegara a un método genérico para manejar las varianzas de direcciones en una sola tabla, sería el camino a seguir. Su código y estructura serían mucho más simples a un costo insignificante (en mi opinión) de algunos campos de datos vacíos.

Answer 4

Definitivamente hay una corriente de pensamiento que sostiene que los campos NULL son malos, en sí mismos. La teoría relacional exige que las bases de datos consistan en hechos, y los NULL son la ausencia de hechos. Por lo tanto, una base de datos rigurosamente diseñada no tendría columnas con nulos.

Su colega propone algo que está en el camino hacia la 6ta Forma Normal, donde todas las tablas consisten en una clave principal y como máximo en otra columna. Solo en ese esquema no tendríamos tablas llamadas customer_info_fr. Eso no está normalizado. Muchos países pueden incluir ENTRY_CODE en sus direcciones. Entonces necesitaríamos address_entry_codes y address_floor_numbers. Sin mencionar address_building_number y address_building_name, ya que algunos lugares se identifican por su número y otros por su nombre.

Es completamente exacto y veraz como un diseño lógico. ¡Desgraciadamente desde una perspectiva física es Teh Suck! La consulta más simple - select * from addresses - se convierte en una combinación de múltiples tablas, y las combinaciones externas en eso. Las columnas anulables son una forma de reconciliar el diseño feo con la dura verdad, "no puedes romper las leyes de la física". Las columnas anulables nos permiten combinar conjuntos de datos disjuntos en una sola tabla, aunque a costa de manejar valores nulos (pueden afectar la recuperación de datos, el uso de índices, las matemáticas, etc.).

Answer 5

Haga lo que haga, no vaya por la ruta EAV. Esta es una receta para una base de datos de bajo rendimiento, mucho, mucho peor que unos pocos campos vacíos.

Si debe tener tablas relacionadas separadas para las diferentes situaciones, mucho de eso dependerá de cuán diferentes sean las entidades y cómo se consultarán. Si va a consultar en todas las categorías, encontrará que unirse a varias tablas para obtener todos los datos que puede o no necesitar es una pesadilla (no sé si Alemania estará en mi conjunto de resultados, así que me uno a las tablas de detalles de Alemania, ¡ay! no es necesario). Puede ser mucho más simple manejar nulos que intentar averiguar a cuál de muchas tablas necesita unirse (y recordar siempre que se unió a esas tablas).

Sin embargo, si nunca consultará las entidades y los campos tienen sentido por separado, colóquelos en una tabla separada.