Lorsque l'intégrité référentielle est pas approprié?

Question

Je comprends la nécessité d'avoir l'intégrité référentielle pour limiter les valeurs spécifiques à l'entrée ou peut-être les empêchant de retrait sur une demande de suppression. Cependant, je ne suis pas clair quant à un cas d'utilisation valable qui exclurait ce mécanisme de toujours utilisé.

Je suppose que cela tomberait dans plusieurs sous-questions:

1. Quand l'intégrité référentielle ne convient pas?
2. Est-il approprié d'avoir des champs contenant des sous-ensembles multiples et / ou éventuellement incomplètes de la liste d'une clé étrangère?
3. En règle générale, si cela est une décision de conception de structure de schéma ou une décision de conception d'interface? (Ou peut-être ni ou les deux)

Pensées

Answer 1

Quand l'intégrité référentielle ne convient pas?

intergrity référentielle si généralement pas utilisé sur Les entrepôts de données où les données est une copie en lecture seule d'un datbase transactionnel. Un autre exemple quand vous auriez pas besoin RI est quand vous voulez enregistrer des informations qui comprend rangée ids; le maintien de l'intégrité référentielle pour une lecture seule table log est une perte de base au-dessus.

Est-il approprié d'avoir des champs contenant des sous-ensembles multiples et / ou éventuellement incomplètes de la liste d'une clé étrangère?

Parfois, vous souciez plus sur la saisie des données que la qualité des données. Imaginez que vous êtes une grande quantité de concentration de données provenant de systèmes disparates qui chacun dans leur propre droit souffrent de problèmes de qualité des données. Parfois, vous êtes après le bien de la qualité des données et avoir tout en un seul endroit, même avec les touches cassées, etc. représente un point de départ pour aller vers une véritable qualité des données. Ce n'est pas idéal, mais il ne se produit que les PROFITE pourraient l'emporter sur les compromis.

En règle générale, devrait-il être une décision de conception de structure de schéma ou une décision de conception d'interface? (Ou peut-être ni ou les deux)

Tout sur le développement des systèmes est centrée sur la sécurité de l'information, et un élément clé de cette est l'intégrité des données. La structure de base de données devrait se pencher vers l'application de ces choses lorsque cela est possible, mais vous êtes souvent affaire avec des systèmes de bases de données modernes. Parfois, votre source de données est un ancien AS400 scolaire avec des applications longue vétustes. Parfois, vous devez construire une couche de données et d'affaires qui assurent l'intégrité des données.

Juste mes pensées.

Answer 2

Le seul cas que je l'ai entendu parler est de savoir si vous allez charger une grande quantité de données dans votre base de données; dans ce cas, il peut être judicieux de transformer l'intégrité référentielle au large, aussi longtemps que vous savez avec certitude que les données sont valides. Une fois que votre chargement / migration terminée, l'intégrité référentielle doit être rallumé.

Il existe des arguments au sujet de mettre les règles de validation des données dans le code de programmation par rapport à la base de données, et je pense que cela dépend des cas d'utilisation de votre logiciel. Si une seule application est la seule voie vers la base de données, vous pouvez mettre la validation dans le programme lui-même et probablement bien se passer. Mais si plusieurs programmes utilisent la base de données en même temps (par exemple votre application et votre demande d'ami), vous voulez des règles métier dans la base de données afin que vos données sont toujours valides.

Par « règles de validation », je parle de règles telles que « articles dans le panier> 0 ». Vous pouvez ou ne voulez pas que les règles de validation. Mais je pense que les clés primaires / étrangères sont toujours importants (ou vous pourriez trouver plus tard que vous souhaitez vous les aviez). Je pense qu'ils sont nécessaires si vous voulez faire la réplication à un moment donné.

Answer 3

1. Quand l'intégrité référentielle ne convient pas?

   Parfois, lorsque vous copiez beaucoup des dossiers en vrac, ou la restauration données à partir d'une sorte de sauvegarde, il est pratique pour désactiver temporairement les contraintes de référentiel l'intégrité.

2. Est-il approprié d'avoir des champs contenant des sous-ensembles multiples et / ou éventuellement incomplètes de la liste d'une clé étrangère?

   Duplication des données de cette façon va contre le concept de normalisation. Il y a sont avantages et inconvénients à cette approche.

3. En règle générale, devrait-il être une décision de conception de structure de schéma ou une décision de conception d'interface? (Ou peut-être ni ou les deux)

   Je considérerais une conception de schéma décision. Pensez à la meilleure façon pour modéliser votre problème relationnel termes. Utilisez la base de données de la façon dont il était destiné.

Answer 4

L'intégrité référentielle serait toujours appropriée si elle ne venait pas au prix de la performance, l'évolutivité et / ou d'autres caractéristiques.

Dans certaines applications, l'intégrité référentielle peuvent être échangés pour quelque chose de plus important que la qualité des données.

Answer 5

1. Jamais, bien que quelques personnes dans le NoSQL, la multi-valeur et royaumes oo-db se sentiront différemment. Ne pas les écouter, ils se trompent.
2. Oui. Par exemple, si un véhicule est identifié de façon unique comme (ID_lot, vin), puis ID_lot est une clé étrangère à la table du lot. Si vous voulez trouver toutes les images pour beaucoup, vous pouvez rejoindre la table vehicle_pictures droit à la table du lot, en utilisant un sous-ensemble de la clé de vehicle_pictures (ID_lot dans (ID_lot, vin)). Ou, suis-je pas vous comprendre?
3. Schéma, l'interface vient en deuxième position. Si le schéma est mauvais, ayant une belle interface est pas un objectif à long terme.