Dev Faq
9
votes

Est-il mauvais d'utiliser des relations redondantes?

Supposons que j'ai les tables suivantes dans ma base de données:

tables

Maintenant, toutes mes questions dépendent de la table de l'entreprise. Est-ce une mauvaise pratique de donner à toutes les autres relations une relation (redondante) à la table de la société pour simplifier mes requêtes SQL?

EDIT 1: Le fond est un problème d'utilisation avec un cadre. Voir Django: limitant les données de modèle .

edit 2: aucun tuple ne changerait sa société.

edit 3: Je n'écris pas les requêtes MySQL. J'utilise une couche d'abstraction (Django).

3 commentaires

Le mot "relation" ne signifie pas ce que vous avez apparemment voulu dire. Une relation dans le modèle de base de données relationnelle correspond à ce que la plupart des gens appellent une table. Cela n'a rien à voir avec les relations entre les données dans différentes tables.

Oui tu as raison. Je l'ai corrigé.

@Svenwalter Veuillez mettre à jour la question avec la table dans un bloc de code ( ) car le fichier d'image externe n'est plus disponible. Je partage la douleur de ne pas avoir de tables appropriées en SE (les Devs sont courtises de ne jamais la rendre disponible), mais au moins, nous pouvons les imiter avec des blocs de code au lieu de s'appuyer sur des outils externes.

7 Réponses :

5
votes

Est-ce une mauvaise pratique de donner à tous les autres table une relation (redondante) à la table de la société pour simplifier mes requêtes SQL?

Oui, absolument, comme cela impliquerait de mettre à jour chaque relation redondante lorsque vous mettez à jour le client des relations avec une entreprise ou une section vers une entreprise - et si vous manquez une telle mise à jour, vous avez maintenant une base de données complète de données redondantes. C'est une mauvaise dénoralisation.

Si votre point est de simplifier votre SQL, envisagez d'utiliser des vues pour "apporter" les données parent. Voici une vue qui tire Company_ID dans le contrat, par rejoindre le client: xxx

Cette jointure est simple, mais pourquoi la répéter encore et encore? Écrivez-le une fois, puis utilisez la vue dans d'autres requêtes.

Beaucoup de RDBMS (mais pas tous) peuvent même optimiser la jointure si vous ne mettez aucune colonne de client dans la liste SELECT ou la clause de la requête basée sur la vue, tant que vous faites du contrat.Customer_id a une contrainte d'intégrité référentielle à la clé étrangère sur le client.customer_id. (En l'absence d'une telle contrainte, la jointure ne peut pas être omise, car elle serait alors possible pour un contrat.Customer_id qui n'existait pas au client. Puisque vous ne voudrez jamais que , vous allez ajouter la contrainte de clé étrangère.)

L'utilisation de la vue permet de réaliser ce que vous voulez, sans que le temps limite de devoir mettre à jour les tables de l'enfant, sans que l'espace aérien de la fabrication des rangées d'enfants plus large en ajoutant la colonne redondante (et cela commence vraiment à la matière lorsque vous avez de nombreuses lignes, comme plus large la ligne, les moins de lignes peuvent s'intégrer à la mémoire à la fois), et surtout, sans possibilité de données incohérentes lorsque le parent est mis à jour, mais le les enfants ne sont pas.

0 commentaires
9
votes

C'est une mauvaise pratique car vos données redondantes doivent être mises à jour de manière indépendante et donc redondante. Un processus qui est semé de potentiel d'erreur. (Même la cascade automatique doit être attribuée et maintenue séparément)

En introduisant cette relation que vous dénormez efficacement votre base de données. La dénormalisation est parfois nécessaire pour des performances, mais de votre question, cela ressemble à vous simplifier votre SQL.

Utilisez d'autres mécanismes pour résumer la complexité de votre base de données: Vues, ​​Procs stockés, UDFS

5 commentaires

De nombreux SDBM ont des mises à jour en cascade. Changer l'ID de la société dans la table de la société va cascader vers toutes les tables qui le font référence.

SIRIDE: C'est un bon point mais le maintien de la cascadabilité de vos liens reste une étape de maintenance supplémentaire qui doit être effectuée et doit être faite correctement. Plus simple est mieux dans mon livre. Coller avec vos clés étrangères et vivre avec le jointure supplémentaire dans vos questions.

Je vois que c'est une mauvaise idée. Merci pour votre aide ... Je dois trouver une autre solution.

Ce n'est pas toujours une mauvaise pratique. C'est par exemple assez courant de le faire avec l'identifiant du locataire lorsqu'il s'agit de multiténier - car il ne change pas (ne comptant pas la fusion de locataires et des choses rares comme ça), les inconvénients sont plus ou moins inexistants. Un autre cas d'utilisation valide serait dénormaliser pour des raisons de performance.

Plus la mise à jour en cascade ne doit jamais être utilisée si vous avez de grandes tables enfants, car vous pouvez causer de graves problèmes de performance.

2
votes

Si vous voulez dire, ajoutez une colonne de l'entreprise à chaque table, c'est une mauvaise idée. Cela augmentera le potentiel des problèmes d'intégrité des données (c'est-à-dire qu'il est changé dans une table mais pas les 6 autres où il devrait).

0 commentaires
-1
votes

Cela dépend de vos exigences fonctionnelles pour "performance". Votre application va-t-elle gérer une demande importante? Simplifier les jointures offre des performances. Outre le matériel est bon marché et le temps de retour est important.

Plus vous allez plus profondément dans la base de données des formulaires normaux - vous économisez de l'espace mais lourd sur le calcul

1 commentaires

Vous devriez avoir une base de données énorme avant que les jointures provoquent des problèmes de performance si vous indexez correctement. Curieusement, les personnes que je sais qui gèrent les bases de données avec des trillions d'enregistrements utilisent toujours des jointures, mais c'est parce que les concepteurs de base de données de ces types de systèmes étaient compétents.

4
votes

Si vous avez vraiment besoin de simplifier les choses, c'est là qu'un Voir < / a> (ou plusieurs vues) serait utile.

Avoir une colonne pour la société dans votre employé View ne serait pas mal normalisé à condition qu'il soit dérivé d'une jointure à la section.

0 commentaires
1
votes

Je dirais que je ne dis pas dans l'affaire de l'OP, mais parfois c'est utile (juste comme goto;).

une anecdote:

Je travaille avec une base de données où la plupart des tables ont une clé étrangère pointant sur une table racine pour les comptes. Les numéros de compte sont externes à la base de données et ne sont pas autorisés à être modifiés une fois émis. Il n'est donc pas dangereux de modifier les numéros de compte et de ne pas mettre à jour toutes les références dans la DB. Je trouve également que cela est également considérablement plus facile de saisir des données à partir de tables clés par numéro de compte au lieu de devoir se joindre complexe et coûteux de se joindre à la hiérarchie pour accéder au tableau des comptes racine. Mais dans mon cas, nous n'avons pas tant de clé étrangère en tant qu'identificateur externe (c'est-à-dire du monde réel), ce n'est donc pas tout à fait la même chose que la situation de l'OP et semble approprié une exception.

0 commentaires
7
votes

Ce que vous demandez est de violer la troisième forme normale dans votre conception. Ce faisant, ce n'est pas quelque chose à faire sans bonne raison car, en créant une redondance, vous créez des erreurs et des incohérences dans vos données. En outre, "Simplifier" le modèle avec des données redondantes à soutenir certaines opérations est susceptible de compliquer d'autres opérations. De plus, les contraintes et autres logiques d'accès aux données devront probablement être dupliqués inutilement.

0 commentaires

Articles qui pourrait vous intéresser :

 cassandra vs recherche élastique vs toute autre suggestion de conception
La gestion de la concurrence très importante n'est-elle pas possible?
Le moyen le plus efficace de vérifier s'il existe plusieurs relations
Référencer l'ID inséré dans plusieurs transactions d'insertion dans Postgres