Normalización de base de datos

Question

Recientemente he dividido una tabla de base de datos muy grande en tablas más pequeñas y manejables y, en general, estoy satisfecho con mi trabajo y creo que los datos están normalizados correctamente.

Pero hay una excepción a esto. Las tablas en cuestión provienen de una base de datos de productos que almacena información sobre (lo adivinó) productos que vende la empresa. He separado gran parte de la información en dos tablas: ProductBase y ProductBasePackaging.

Estas tablas contienen el paraguas de la información que es relevante para un número de pieza base en lugar de un producto individual (hay múltiples productos para cada número base).

ProductBase contiene más información general, como MarketingCopy, Keywords etc. y también información sobre el material de construcción es decir, componentes etc.

Y ProductBasePackaging por supuesto mantiene datos sobre el envase.

Ahora que estoy escribiendo la aplicación para la manipulación de datos, estoy comenzando a adivinarme a mí mismo. Parece que me he vuelto más difícil ahora que tengo que hacer un seguimiento de varias tablas que usan la misma clave (el número de parte de la base). ¿O tengo razón en haberlos separado como tal y quizás haber dado un paso más y haber separado la construcción en su propia mesa también?

Soy bastante versado en el uso de sql, pero esta es la primera vez que alguna vez he tenido que diseñar una estructura de base de datos, y mucho menos reestructurar una gran base de datos existente. Entonces, básicamente, lo que estoy preguntando es si debería tener varias tablas con la misma clave separadas por tipo de datos o mantener las cosas juntas en la única tabla donde puedo hacer referencia a todo lo que necesito de una tabla con la misma clave.

Lo siento, sé que era mucho para leer, espero que tenga sentido, ¡y gracias a todos los que lo lograron!

Answer 1

normalización podría ser como un dolor en el ** un momento - pero confía en mí, en el largo plazo, podrás contenta que lo hizo! Las mesas "planas" no normalizadas con todo menos el fregadero de la cocina en ellas se volverán muy difíciles de manejar con el tiempo, las inconsistencias en los datos se acumularán y, antes de que te des cuenta, tienes una enorme pila de basura - errrg - datos que no ya tiene sentido!

Sí, tablas de unión pueden ser un poco de trabajo - pero especialmente para la visualización de datos, que debería salir vistas que pueden ayudarle a escribir los JOINs una vez y luego sólo tiene que utilizar como "tablas virtuales" que sujetan todo de nuevo.

La normalización de la base de datos - hasta aproximadamente 3NF - es una buena cosa (TM) seguro! Siempre recomendaría hacerlo, y tal vez en ese momento presente una desnormalización limitada donde las necesidades de rendimiento lo requieran, pero solo de una manera muy controlada, y con su total comprensión y conocimiento de que de hecho está desnormalizando algo de nuevo .

Answer 2

La respuesta es depende.

Depende de lo que normalmente consulta, cómo consulta normalmente, con qué frecuencia consulta, qué tan grande es la tabla para contener todos los datos ... etc. Depende.
Un ejemplo de cuándo podría no querer normalizar sería si necesita consultar datos agregados o derivados regularmente y el proceso de compilación lleva mucho tiempo. Por lo general, aunque creo que los datos deben ser normalizados.

Dicho esto, no estoy seguro de lo que usted describe es "Normalización" tanto como su separación. La normalización implicaría eliminar datos duplicados en diferentes columnas.

Tomemos su ejemplo de embalaje ... Me parece que ha hecho un registro en algún ProductBasePackaging que está relacionado por PartNumber con el o algo así.

En realidad, si estuviera normalizando los datos ... tendría una fila ProductBasePackaging solo para cada tipo de embalaje ... como que puede enviar 1000 productos diferentes pero solo usar 10 tipos diferentes de cajas. ProductBasePackaging tendría 10 filas, cada una con información en una caja única ...entonces ProductBase haría referencia a su caja requerido por PackagingID