2010-07-27 13 views
7

Supongamos que tengo las siguientes tablas en mi base de datos:¿Es malo usar relaciones redundantes?

tables http://www.freeimagehosting.net/uploads/a5ef036857.png

Ahora todas mis preguntas dependen de la tabla de la empresa. ¿Es una mala práctica dar a cada otra mesa una relación (redundante) con la tabla de la empresa para simplificar mis consultas sql?

Editar 1: El fondo es un problema de uso con un marco. Ver Django: limiting model data.

Editar 2: No tuple cambiaría su empresa.

Editar 3: No escribo las consultas de mysql. Yo uso una capa de abstracción (django).

+0

La palabra "relación" no significa lo que aparentemente pretendía que significara. Una * relación * en el modelo de base de datos relacional corresponde a lo que la mayoría de la gente llama una tabla. No tiene nada que ver con las relaciones entre los datos en diferentes tablas. – sqlvogel

+0

Sí, tienes razón. Lo he corregido – svenwltr

+0

@SvenWalter actualice la pregunta con la tabla en un bloque de código ('

') ya que el archivo de imagen externo ya no está disponible. Comparto el dolor de no tener las tablas adecuadas en SE (los desarrolladores están empeñados en nunca hacerlo disponible), pero al menos podemos emularlos con bloques de código en lugar de depender de herramientas externas. –
                        
                            
    ADTC
                                
                            
                        
                    

Respuesta

7

Es una mala práctica porque sus datos redundantes deben actualizarse de forma independiente y, por lo tanto, de forma redundante. Un proceso lleno de potencial de error. (Incluso la cascada automática debe asignarse y mantenerse por separado)

Al introducir esta relación, se desnormaliza de forma efectiva su base de datos. La desnormalización a veces es necesaria en aras del rendimiento, pero a partir de su pregunta, parece que simplifica su SQL.

utilizar otros mecanismos para abstraer la complejidad de su base de datos: vistas, procedimientos almacenados, UDF

+0

Muchos RDBM tienen actualizaciones en cascada. El cambio del ID de la compañía en la tabla de la empresa se realizará en cascada a todas las tablas que lo mencionen. – siride

+1

siride: Ese es un buen punto, pero mantener la capacidad de conversión en cascada de sus enlaces sigue siendo un paso adicional de mantenimiento que debe hacerse y debe hacerse correctamente. Más simple es mejor en mi libro. Quédese con sus claves foráneas y viva con el JOIN extra en sus consultas. –

+0

Veo que es una mala idea. Gracias por su ayuda ... Tengo que buscar otra solución. – svenwltr

4

¿Es una mala práctica dar a todas las demás tablas una relación (redundante) con la tabla Company para simplificar mis consultas SQL?

Sí, en absoluto, ya que significaría actualizar cada relación redundante al actualizar el cliente de relaciones con la empresa o sección a la empresa, y si pierde una actualización, ahora tiene una base de datos llena de redundancia. Es una mala desnormalización.


Si su objetivo es simplemente simplificar su SQL, considere el uso de vistas para "llevar adelante" los datos primarios. Aquí está una vista que tira Company_id en contrato, por Join a través del cliente:

create view contract_customer as 
select 
    a.*, 
    b.contract_id, b.company_id 
from 
    contract a 
    join customer b on (a.customer_id = b.customer_id); 

Esta unión es simple, pero ¿por qué repetir una y otra vez? Escríbelo una vez y luego use la vista en otras consultas.

Muchos (pero no todos) RDBMS pueden incluso optimizar la unión si no coloca columnas del cliente en la lista de selección o en la cláusula de la consulta en función de la vista, siempre que haga contract.customer_id tener una restricción de integridad referencial de clave externa en customer.customer_id. (En ausencia de tal restricción, no se puede omitir la combinación, porque entonces podría existir un contrato.customer_id que no existía en el cliente. Como nunca querrá ese, tendrá que agregue la restricción de clave externa)

El uso de la vista logra lo que desea, sin el tiempo invertido de tener que actualizar las tablas secundarias, sin el espacio adicional de hacer que las filas secundarias sean más anchas agregando la columna redundante (y esto realmente comienza importar cuando tiene muchas filas, ya que cuanto más ancha sea la fila, menos filas caben en la memoria a la vez), y lo más importante, sin la posibilidad de datos incoherentes cuando el padre se actualiza pero los niños no.

2

Si se refiere a añadir una columna Compañía para cada mesa, que es una mala idea. Aumentará el potencial de problemas de integridad de datos (es decir, se cambia en una tabla, pero no en las otras 6 donde debería).

-1

Eso depende de sus requisitos funcionales para 'Rendimiento'. ¿Su aplicación va a manejar una gran demanda? Simplificar JOINS cuenta con rendimiento. Además el hardware es barato y el tiempo de entrega es importante.

Cuanto más profundo se llegue en las formas normales de bases de datos - a ahorrar espacio pero cargados de cómputo

+0

Debería tener una gran base de datos antes de que las uniones causen problemas de rendimiento si indexa correctamente. Curiosamente, las personas que conozco que administran bases de datos con billones de registros todavía usan combinaciones, pero eso se debe a que los diseñadores de bases de datos de esos tipos de sistemas eran competentes. – HLGEM

4

Si realmente necesita para simplificar las cosas, aquí es donde un View (o múltiples visitas) sería muy útil.

Tener una columna para la empresa en su empleado ver no estaría mal normalizado siempre que se derive de una sección de unión.

1

Yo diría que no en el caso del OP, pero a veces es útil (al igual que goto;).

Una anécdota:

Estoy trabajando con una base de datos donde la mayoría de las mesas tienen una clave externa que apunta a una tabla raíz de las cuentas. Los números de cuenta son externos a la base de datos y no pueden cambiarse una vez emitidos. Por lo tanto, no hay peligro de cambiar los números de cuenta y no actualizar todas las referencias en el DB. También me parece que también es considerablemente más fácil obtener datos de tablas marcadas por número de cuenta en lugar de tener que realizar uniones complejas y costosas en la jerarquía para acceder a la tabla de la cuenta raíz. Pero en mi caso, no tenemos tanta clave externa como un identificador externo (es decir, del mundo real), por lo que no es lo mismo que la situación del OP y parece adecuado para una excepción.

5

Lo que se pregunta es si violar la tercera forma normal en su diseño. Hacerlo no es algo que deba hacerse sin una buena razón, ya que al crear redundancia crea la posibilidad de errores e inconsistencias en sus datos. Además, "simplificar" el modelo con datos redundantes para respaldar algunas operaciones puede complicar otras operaciones. Además, las limitaciones y otra lógica de acceso a los datos probablemente tendrán que duplicarse innecesariamente.