¿Se considera esto una falla de forma normal?

Question

Al almacenar la religión de un usuario en una "Tabla de usuario", de modo que si miras hacia abajo en una columna verías "cristiano" muchas veces, "musulmán" muchas veces, etc. ¿Consideras una falla de una forma normal? ¿Cual forma?

La forma en que lo veo:

• 1NF: No hay columnas que se repiten.

• 2nf: No hay una clave primaria concatenada, por lo que esto no se aplica.

• 3nf: No hay dependencia de un atributo que no sea de tecla.

Almacenamiento de la religión de esta manera el usuario no parece fallar en cualquier forma normal, sin embargo, parece muy ineficiente. ¿Comentarios?

Answer 1

Su diseño es compatible con todas las formas normales. Está bien que tu atributo tenga un valor de cadena. El tamaño del tipo de datos es irrelevante para la normalización.

El objetivo de la normalización no es la eficiencia del almacenamiento físico: el objetivo es evitar anomalías. Y para admitir la eficiencia lógica, es decir, almacenar un hecho dado una sola vez. En este caso, el hecho de que el usuario en una fila determinada es cristiano.

Answer 2

La principal desventaja de almacenar la columna de esa manera es en el espacio de almacenamiento a medida que el número de filas aumenta.

En lugar de una columna de caracteres, puede usar ENUM() si tiene un conjunto fijo de opciones que rara vez o nunca cambiará, y aún así evitará crear una tabla adicional de opciones de religión a la que esta tenga una clave externa . Sin embargo, si las elecciones serán fluidas, las reglas de normalización preferirían que las elecciones se coloquen en su propia tabla con una clave externa en su tabla de usuarios.

Existen otras ventajas además del espacio de almacenamiento para mantenerlas en otra tabla. Modificarlos es muy fácil. Para cambiar Christian a Christianity, se puede realizar un solo cambio en la tabla de las religiones, en lugar de hacer la potencialmente costosa (si usted tiene un montón de filas y la religión no está indexado)

UPDATE users SET religion='Christianity' WHERE religion='Christian' 

... puede hacer lo mucho más simple y más barato

UPDATE religions SET name='Christianity' WHERE id=123 

por supuesto, también exigir integridad de datos tecleando en una tabla religiones. Resulta imposible insertar un valor no válido como el Christain mal escrito.

Answer 3

Supongo que hay una lista de religiones válidas; Si acabas de hacer que el usuario ingrese su propia cadena, entonces debes almacenarla en la tabla de usuarios y esto es discutible.

Supongamos que las religiones se almacenan en su propia tabla. Si sigue prácticas bien establecidas, esta tabla tendrá una clave principal que es un número entero, y todas las referencias a las entradas en la tabla en otras tablas (como la tabla de usuarios) serán claves externas. El método de cadena de almacenamiento de religión no viola ninguna forma normal (ya que el nombre de una religión es una clave candidata para la tabla de religión), pero viola la práctica de no usar cadenas como claves.

(Esta es una diferencia interesante entre la teoría y la práctica del álgebra relacional. En teoría, una cadena no es diferente de un entero; ambos son valores matemáticos atómicos. En la práctica, las cadenas tienen una gran cantidad de gastos generales que conduce programadores para no usarlos como claves.)

Por supuesto, hay otras formas (como ENUM para algunos RDBMS) de almacenar una lista de valores posibles, cada uno con sus propias ventajas y desventajas.

Answer 4

Sus formas normales son un poco torcidas. La segunda forma normal es que el resto de la fila depende de "la clave completa". La tercera forma normal es que el resto de la fila depende de "nada más que la clave". (Así que ayudame Codd).

No, su situación como se describe no infringe ninguna de las tres primeras formas normales. (Podría violar el sexto, dependiendo de otros factores).

Answer 5

Existen algunos inconvenientes con este enfoque (en comparación con el uso de una clave externa) con los que deberá asegurarse de que está de acuerdo. 1 - almacenamiento de desechos. 2 - más lento para consultar por religión 3 - alguien puede poner datos que no coinciden, por ejemplo, inserte manualmente "Jedi" o algo que no considere correcto 4 - no hay forma de tener una lista de posibles religiones (por ejemplo, si no hay una determinada religión en su tabla, por ejemplo, Zoroastrian) pero aún desea que sea una posibilidad válida 5 - mayúsculas incorrectas pueden causar problemas 6 - el espacio en blanco alrededor de la cadena podría causar problemas

El profesional principal con esta técnica es que los datos se extraen más rápido (no se unen a una tabla) y también es más rápido de leer para un humano.