Relations de base de données circulaires. Bon, mauvais, exceptions?

Question

J'ai retardé le développement de cette partie de mon application pour la seule raison que je veux faire cela de façon circulaire mais que je ressens une mauvaise idée de ce que mes professeurs me rappellent à l'école.

J'ai une conception d'un système de commande, sans tenir compte du tout ce qui ne concerne pas cet exemple, je suis parti avec:

• CreditCard
• client
• Commander

Je le veux pour que,

• Cust omers peuvent avoir des cartes de crédit (0-n)
• Les clients ont des commandes (1-n)
• Les commandes ont un client (1-1)
• les commandes ont une carte de crédit (1-1)
• crédit les cartes peuvent avoir un client (1-1) (ids uniques afin que nous puissions ignorer l'unicité du numéro de cc, mari/femme peut partager des instances cc ect)

Fondamentalement, la dernière partie est où la question apparaît, parfois crédit les cartes sont refusées et elles souhaitent en utiliser une autre, cela nécessite de mettre à jour leur carte 'actuelle' mais cela ne peut que changer la carte utilisée pour l'ordre du chapeau, pas les autres commandes que le client peut avoir sur le disque.

Effectivement ceci crée une conception circulaire entre les trois tables.

solutions possibles: Soit

Créer la conception circulaire, donner des références:

• cc ref à l'ordre,
• ref client cc
• ref client pour commander

ou

• ref client cc
• ref client commander
• créer une nouvelle table qui fait référence à tous les trois ids de table et mettre unique sur l'ordre de sorte qu'une seule cc peut être courant à cet ordre à tout moment

Essentiellement les deux modélisent le même design mais traduisent différemment, je préfère cette dernière option à ce moment parce qu'elle semble moins circulaire et plus centrale. (Si cela fait même sens)

Mes questions sont,

• si tout sont les avantages et les inconvénients de chacun?
• Quels sont les pièges des relations/dépendances circulaires?
• Est-ce une exception valide à la règle?
• Y a-t-il une raison pour laquelle je devrais choisir le premier sur le dernier?

Merci et faites-moi savoir s'il y a quelque chose dont vous avez besoin clarifié/expliqué.

--update/Edit--

J'ai remarqué une erreur dans les exigences je. Fondamentalement laissé tomber la balle en essayant de simplifier les choses pour SO. Il y a une autre table pour Payments qui ajoute une autre couche. La capture, les commandes peuvent avoir plusieurs paiements, avec la possibilité d'utiliser des cartes de crédit différentes. (Si vous voulez vraiment savoir même d'autres formes de paiement). En déclarant cela ici parce que je pense que le problème sous-jacent est toujours le même et cela ne fait qu'ajouter vraiment une autre couche de complexité.

Answer 1

Un client peut avoir 0 ou plusieurs cartes de crédit associées, mais l'association est dynamique - elle peut aller et venir. Et comme vous le faites remarquer une carte de crédit peut être associée à plus d'un client. Donc, cela finit par être une table n: m, peut-être avec une colonne de drapeau pour "actif". Une commande a une relation statique avec 0 ou 1 carte de crédit, et une fois la vente terminée, vous ne pouvez pas jouer avec la valeur cc, peu importe ce qu'il advient de la relation entre le cc et le client. La table de commande doit stocker de manière indépendante toutes les informations associées au cc au moment de la vente. Il n'y a aucune raison d'associer la vente avec une autre colonne de carte de crédit dans une autre table (qui pourrait changer - mais cela n'affecterait pas la vente).

Answer 2

Hmm?

Un client a plusieurs cartes de crédit, mais seulement une en cours. Une commande a une seule carte affectée. Quand un client achète quelque chose, sa carte par défaut est essayée en premier, sinon, il peut changer sa carte principale?

Je ne vois aucune référence circulaire ici; Lorsque la carte de crédit d'un utilisateur change, ses commandes restent les mêmes. Vos tables finiraient comme:

• client: id, carte actuelle
• Cartes de crédit: id, nombre, CUSTOMER_ID
• Ordre: id, Card_id, CUSTOMER_ID

Edit: Oups, j'ai oublié un champ, merci.

Answer 3

Je pense que le problème est avec la modélisation de l'Ordre. Au lieu d'une commande a une carte de crédit, un ordre devrait pouvoir être associé à plus d'une carte de crédit dont une seule est active à tout moment. Essentiellement, l'ordre et le crédit sont plusieurs à plusieurs. Afin de modéliser ceci dans DB, vous devez introduire une table d'association, disons PaymentHistory. Maintenant, lorsqu'une commande nécessite une nouvelle carte de crédit, vous pouvez simplement créer une nouvelle carte de crédit, l'associer à la commande et marquer l'historique PaymentHistory comme actif.

Answer 4

Peu importe la raison pour laquelle vos données ont des relations circulaires, vous serez beaucoup plus heureux si vous "oubliez" de déclarer l'un d'eux afin que vos tables aient un ordre de chargement groupé.

C'est pratique quand on s'y attend le moins.

Answer 5

Il s'agit d'un an, mais il y a quelques points à faire valoir. NB Pour les processus NON COMPTATIFS en ligne: Le Client serait mieux défini comme Acheteur et il y aurait probablement un autre type de client - le Bénéficiaire/le Bénéficiaire. Vous pouvez acheter/acheter des billets d'avion et des fleurs, etc. pour d'autres personnes, de sorte que ces deux rôles doivent être clairement séparés car ils impliquent différents processus d'affaires (un à payer et l'autre à envoyer les marchandises).

S'il ne s'agit pas d'un compte, vous ne devriez pas conserver les détails de votre carte de crédit. C'est un risque de sécurité - et vous mettez l'acheteur en péril en gardant cette information. Les cartes de crédit sont traitées en temps réel, puis les informations doivent être jetées.

COMPTE CLIENTS: La seule exception serait lorsque quelqu'un a ouvert un compte et fourni les informations de sa carte de crédit pour utilisation lors d'achats ultérieurs. Dans un tel cas, les modifications apportées aux informations de carte de crédit s'effectueraient en dehors de la transaction - dans le cadre du processus de gestion des comptes.

Le principal est de vous assurer que vous comprenez parfaitement les processus métier avant de commencer la modélisation et le codage.