¿Cuándo la integridad referencial no es apropiada?

Question

Entiendo la necesidad de tener integridad referencial para limitar valores específicos en la entrada o posiblemente evitar que se eliminen a petición de eliminación. Sin embargo, no tengo claro qué es un caso de uso válido que excluya que este mecanismo siempre se use.

supongo que esto caería en varias sub-preguntas:

1. Cuando es la integridad referencial no es apropiado?
2. ¿Es apropiado tener campos que contengan subconjuntos múltiples y/o posiblemente incompletos de la lista de una clave foránea?
3. Normalmente, ¿debería ser una decisión de diseño de estructura de esquema o una decisión de diseño de interfaz? (O posiblemente ninguno o ambos)

¿Pensamientos?

Answer 1

¿Cuándo no es apropiada la integridad referencial?

Intergrity referencial si normalmente no se usa en Data Warehouses donde los datos son una copia de solo lectura de una base de datos transaccional. Otro ejemplo de cuando no necesitaría RI es cuando desea registrar información que incluye identificadores de fila; mantener la integridad referencial para una tabla de registro de solo lectura es un desperdicio de la sobrecarga de la base de datos.

¿Es apropiado tener campos que contengan subconjuntos múltiples y/o posiblemente incompletos de una lista de claves foráneas?

A veces le importa más la captura de datos que la calidad de los datos. Imagine que está agregando una gran cantidad de datos de sistemas dispares que, por derecho propio, sufren problemas de calidad de datos. A veces busca el bien de la calidad de los datos y tener todo en un solo lugar, incluso con las llaves rotas, etc. representa un punto de partida para avanzar hacia la verdadera calidad de los datos. No es ideal, pero sucede ya que los beneficios podrían superar las compensaciones.

Normalmente, ¿debería ser una decisión de diseño de estructura de esquema o una decisión de diseño de interfaz? (O posiblemente ninguno o ambos)

Todo sobre el desarrollo de sistemas se centra en la seguridad de la información, y un elemento clave de eso es la integridad de los datos. La estructura de la base de datos debe inclinarse hacia la aplicación de estas cosas cuando sea posible, sin embargo, a menudo no se trata de sistemas modernos de bases de datos. A veces, su fuente de datos es un AS400 de la vieja escuela con aplicaciones antiguas y anticuadas. En ocasiones, debe crear una capa de datos y negocios que brinde integridad a los datos.

Sólo mis pensamientos.

Answer 2

1. Nunca, aunque algunas personas en los dominios NoSQL, multivalor y oo-db se sentirán de manera diferente. No los escuches, están equivocados.
2. Sí. Por ejemplo, si un vehículo se identifica únicamente como (lotid, vin), entonces lotid es una clave externa a la tabla de lotes. Si desea buscar todas las imágenes para un lote, puede unirse a la tabla de imágenes del vehículo directamente a la tabla de lotes, utilizando un subconjunto de la clave de las imágenes del vehículo (lotid in (lotid, vin)). O, ¿no te entiendo?
3. Esquema, la interfaz ocupa el segundo. Si el esquema es malo, tener una interfaz agradable no es un objetivo a largo plazo.

Answer 3

El único caso que he oído es si va a cargar una gran cantidad de datos en su base de datos; en ese caso, puede tener sentido desactivar la integridad referencial, siempre que sepa con certeza que los datos son válidos. Una vez que se complete su carga/migración, la integridad referencial se debe volver a activar.

Existen argumentos para poner reglas de validación de datos en el código de programación frente a la base de datos, y creo que depende de los casos de uso de su software. Si una sola aplicación es la única ruta a la base de datos, puede poner la validación en el programa mismo y probablemente esté bien. Pero si varios programas diferentes están utilizando la base de datos al mismo tiempo (por ejemplo, su aplicación y la de su amigo), querrá reglas comerciales en la base de datos para que sus datos sean siempre válidos.

Por 'reglas de validación', estoy hablando de reglas como 'artículos en el carro> 0'. Puede o no querer reglas de validación. Pero creo que las claves primarias/extranjeras siempre son importantes (o podrías encontrar más adelante que desearías tenerlas). Creo que son necesarios si quieres hacer la replicación en algún momento.

Answer 4

La integridad referencial siempre sería apropiada si no fuera a costa del rendimiento, la escalabilidad u otras características.

En algunas aplicaciones, la integridad referencial se puede intercambiar por algo más importante que la calidad de los datos.

Answer 5

1. ¿Cuándo la integridad referencial no es apropiada?

   A veces, cuando está copiando un montón de registros a granel, o la restauración de de datos de algún tipo de copia de seguridad, es conveniente para desactivar temporalmente las restricciones de referencial integridad.

2. ¿Es apropiado tener campos que contengan subconjuntos múltiples y/o posiblemente incompletos de una lista de claves foráneas?

   Duplicar los datos de esta manera va contra el concepto de normalización. Existen ventajas y desventajas de en este enfoque .

3. Normalmente, ¿debería ser una decisión de diseño de estructura de esquema o una decisión de diseño de interfaz? (O posiblemente ninguno o ambos)

   Lo consideraría como un diseño de esquema decisión. Piensa en la mejor forma de para modelar tu problema en términos relacionales . Use la base de datos de la forma en que fue diseñada. .