Discussion :

[iguypouf]

Bonjour à tous,

J'expose ici un problème dont je n'ai pas la réponse... ou en tous les cas dont les résultats sont opposés.

Dans mon problème, j'ai 4 types de contrats différents, dont les informations et attributs sont tellement différents qu'ils sont dans 4 objets différents.
Le contrat principal, nommé souscription, que nous appeleront C.
3 contrats secondaires, nommés A, E et S qui n'existent pas sans un contrat C.

J'ai donc, dans les tables A, E et S une clé relationnelle C_ID m'identifiant le contrat C parent.

Sur chacun de ces contrats, peuvent exister des primes P, qui elles par contre, sont exactement pareilles quel que soit le type de contrat qui la contient.

J'ai donc le choix entre plusieurs solutions :

1) une paire de clés : nTYPE et nOWNER (celle actuellement en place), le OWNER étant interprété différemment par le code en fonction de nTYPE (si nTYPE = 1, nOWNER représente l'ID d'un contrat C

2) 4 clés dont une seule est remplie : C_ID, A_ID, E_ID et S_ID qui lient vers les tables C, A, E ou S en fonction de la prime

3) 4 clés dont la clé C_ID est toujours remplie : en effet, un contrat A, E ou S appartenant toujours à un contrat C, la prime peut être toujours reliée à ce contrat C en direct


Je m'interroge donc au niveau de deux choses : l'efficacité du traitement de l'info selon les besoins et la cohérence et poids physiques de stockage.

Et j'ai ces conclusions :

avec 1), l'avantage, c'est qu'il n'y a aucune redondance d'informations à mon sens. Les deux inconvénients sont que je ne peux utiliser de clé relationnelle, le champ nOWNER ne référençant pas toujours le même objet, et un inconvénient qui sera contrecarré dans le point 3)

avec 2), l'avantage, c'est d'avoir des clés relationnelles forçant la cohérence, tout en indexant facilement les vues. Les deux inconvénients étant d'avoir TOUJOURS 3 champs inutiles, ainsi que le même inconvénient du point 3.

avec 3), l'avantage, c'est que je suis très souvent amené dans le logiciel à sortir une somme, stats, etc de toutes les primes d'un client CL, voire même d'un courtier CO. Je dois donc pour se faire additionner des infos d'une même table ( P ) mais dont la méthode de liaison est différente (tous les P(C) appartenant à des C dont le CL est celui-ci, ainsi que tous les P(A) appartenant à des A qui elles-mêmes appartiennent à des C dont le CL est celui-ci, etc.). Alors que dans ce cas, le P étant toujours relié à un C (même si un sous contrat A, E ou S en est le parent direct), je peux additionner tous les P dont le S a mon client comme CL, d'une fois, dans une seule vue. Les deux inconvénients, c'est que
- j'ai une redondance au niveau de mon C_ID : celui-ci pouvant être retrouvé par simple jointure, dans le cas d'un P(A), en allant chercher le C_ID de mon objet A
- un risque d'incohérence si un objet A change de C, sans que soient mis à jour le C_ID de mon objet P lié à ce sous-contrat A.


J'espère être clair :s

Qu'en pensez-vous ?

[SQLpro]

Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/m...tion/heritage/

A +

[iguypouf]

Merci pour cet article très intéressant.

Dans mon cas, si je l'ai bien interprété, la solution actuelle est la bonne, mais la création d'une vue sur primes, joint à un contrat parent simplifiera ma jointure ?