Identifiants dans une relation diamant entre les tableaux

Question

J'ai quatre tableaux (A, B, C, D) où A est le parent d'un à plusieurs relations avec B et C. C et D sont les parents à une relation un à plusieurs avec table D. Conceptuellement, primaire clés de ces tables pourraient être:

• A: aide
• B: aide, bnum (avec clé étrangère à A)
• C: aide, CNUM (avec clé étrangère à A)
• D: aide, bnum, CNUM (avec les clés étrangères à B et C)

Si les colonnes « num » incrémentation automatique en fonction de chaque ID parent dans la relation plutôt que sur chaque enregistrement. J'ai utilisé cette approche sur une demande antérieure, et ce ne fut pas un problème depuis la création de B et C des dossiers a été fait par un processus séquentiel en générant une nouvelle valeur « num » via un « select max () » requête. On ne m'a jamais vraiment satisfait de l'approche, mais il a fait le travail.

Pour le cas particulier, je travaille maintenant, les dossiers dans les tableaux A et B sont entrées par les utilisateurs est donc pas un problème de génération automatique des id. Dans le cas des tableaux C et D, les enregistrements dans ces tableaux sont générés par de multiples processus de traitement par lots simultanés de sorte que leurs identifiants devront générer une certaine façon. La méthode précédente I énuméré ne fonctionnera pas à faire la condition de course.

Notez que ceci est pour une base de données Oracle, donc je vais utiliser des séquences et non colonnes auto-incrément.

Compte tenu des contraintes ci-dessus, comment vous vous concevoir des tables pour représenter A, B, C et D de sorte que les relations entre les entités sont correctement appliquées et le code d'application ne serait pas nécessaire pour générer des identifiants?

Answer 1

Si je comprends bien, vous aviez une solution où vous pouvez avoir

Table A
-------
100
101
102

Table B
-------
100 1
100 2
101 1

Table C
-------
100 1
100 2
101 1


Table D
-------
100 1 1
100 2 1
100 1 2
101 1 1

etc.

Maintenant, est-il important que les valeurs « num » sont petites et dans une séquence sans entrefer? Sinon, il suffit d'utiliser des séquences pour ceux qui sont trop. Ainsi, vous pouvez obtenir

Table B
-------
100 29125
100 29138
101 29130

Table D
-------
100 29125 401907
100 29138 404911
101 29130 803888

J'utiliser des séquences séparées pour bnum et CNUM. En sélectionnant, vous pouvez (si désiré) utiliser quelque chose comme

SELECT AID, 
      RANK(BNUM) OVER (PARTITION BY AID ORDER BY BNUM) bnum_seq,
      RANK(CNUM) OVER (PARTITION BY AID ORDER BY CNUM) cnum_seq

Answer 2

ou Sequences AutoNumbers doit toujours être généré par le système de base de données, et non par l'application. Pour MSSQL, cela peut être fait en utilisant une procédure stockée et retour « select @@ identité » de la procédure stockée pour donner l'application de l'ID de la ligne insérée.

Les séquences sont grandes pour les clés primaires imo, mais il y a des camps qui adorent le dieu des « clés naturelles ».

La signification des données stockées dans la table, et le sens de la relation est important de répondre à votre question tout à fait, mais les relations peuvent permettre des suppressions en cascade.

Personnellement, je voudrais faire les séquences primaires clés dans chaque table et permettre à des clés étrangères qui ne font pas partie de la clé primaire. Vous définissez vos tables par les principaux objets (comme employé, de la marchandise, magasin), et les relations entre eux serait composée de combinaisons Ainsi, un employé dans un magasin aurait une table « storeemployee » et serait empid la clé primaire , StoreID sans séquence définie. Normalement, je pense en termes de choses comme des objets (qui ont toujours des séquences pour les clés primaires), et les relations entre les objets (avec les ID d'utilisation d'autres tables comme clés primaires combo).

L'espoir qui aide!

Edit: Je dois ajouter que cela permet bien des relations de diamant. Pensez à « magasins » et « employés ». Une table peut être storeemployees, et une autre peut être « storesales ». Les deux identifierait un magasin et un employé, mais ils veulent dire des choses radicalement différentes. On est peut-être les heures de travail, et l'autre chiffre d'affaires réalisé.