Discussion :

[piieerre]

Bonjour à tous

Je vous sollicite afin d'avoir un avis sur la conception d'une base de données. Je vais essayer de vous expliquer le contexte.

Je souhaite créer une base qui va accueillir des données d'assurances de complémentaire santé.
Ces complémentaire santé sont sous la forme de formules ayant chacune leurs propres spécificités. Exemple : hospitalisation, dentaire, optique, etc... avec des sous spécificités. Exemple détaillées d'une formule ci-dessous :
HOSPITALISATION | 100%
Frais de séjour | Frais réels
Chambre particulière | 40€/jour
Lit Accompagnant | 10€/ jour
...
OPTIQUE | 150%
Forfait Supplémentaire si verres progressifs | 200€
...
DENTAIRE
....

Donc si je vous résume, il y a environ une centaine de spécificités au total et donc chaque formule a des valeurs différentes pour ces spécificités.

Donc j'ai pu voir 2 solutions.

1ère solution :
Table formule : stockant les informations de base comme le nom de la formule, le code, l'age mini ou maxi ,etc
Table spécificité : stockant le nom de la spécificité et un id
Table de liaison : ID formule + ID spécificité

2ème solution :
Table formule : stockant les informations de base comme le nom de la formule, le code, l'age mini ou maxi , et toutes les spécificités avec un "code champs" (champ1 , champs 2, champs 3)
Table spécificité : stockant le nom de la spécificité, un ID, un "code champs " (champ1 , champs 2, champs 3)

En fait l'idée c'est d'afficher les données sous forme de tableau HTML et de pouvoir les trier comme on le souhaite.

J'ai testé la 2ème solution. J'arrive à afficher les données sans problème en faisant 2 requetes :
1 requête pour la liste des spécificités
1 requête pour la liste des formules
Et ensuite en PHP, je fais correspondre mes codes champs pour avoir les bonnes valeurs sur les bonnes lignes.

Par contre le problème, c'est que pour gérer ça c'est pas tip top je trouve.
Par exemple si j'ajoute des nouvelles spécificités, il faut que je créé des nouveaux champs dans la table de formule. Et que je supprime ces champs si j'en supprime une.
Je n'aime pas bcp l'idée de modifier dynamiquement la structure des tables.

C'est pour ça je réfléchis à la 1ère solution. C'est celle que je préfère en terme de structure et modélisation.
Mais le hic, c'est qu'à première vue c'est que cela va engendrer bcp plus de requêtes car il faudra que pour chaque formule que j'aille chercher les spécificités.

Pour infos, il y aura entre 300 et 500 formules.

Je vous remercie d'avance pour toute l'aide des avis que vous m'apporterez.

Pierre

[piieerre]

Je vous ai ajouté les 2 ébauches de schémas que vous compreniez bien ^^

[Richard_35]

Bonjour Piieerre,

Eh bien, tu as pratiquement tout dit...

Par contre le problème, c'est que pour gérer ça c'est pas tip top je trouve.
Par exemple si j'ajoute des nouvelles spécificités, il faut que je créé des nouveaux champs dans la table de formule. Et que je supprime ces champs si j'en supprime une.
Je n'aime pas bcp l'idée de modifier dynamiquement la structure des tables.

==> une évolutivité d'une application se traduisant systématiquement par l'ajout de champs est, souvent, signe d'une mauvaise modélisation. "L'applicatif" a remplacé le "conceptuel". Or, comme souvent également, c'est le "conceptuel" qui doit être à la base de tout !

C'est pour ça je réfléchis à la 1ère solution. C'est celle que je préfère en terme de structure et modélisation.
Mais le hic, c'est qu'à première vue c'est que cela va engendrer bcp plus de requêtes car il faudra que pour chaque formule que j'aille chercher les spécificités.

==> ce n'est pas le nombre de requête qui doit influer sur la modélisation !... l'inverse est normal.


Enfin, ça vaudrait peut-être le coup d'externaliser (table spécifique) les sous-catégories en entités à part entière :
HOSPITALISATION | 100%

Frais de séjour

| Frais réels

Chambre particulière

| 40€/jour

Lit Accompagnant

| 10€/ jour

...
OPTIQUE | 150%

Forfait Supplémentaire si verres progressifs

| 200€

[piieerre]

Bonjour Richard et merci pour ta réponse.

J'ai mis à jour le modèle, j'avais oublié de mettre la valeur dans la table intermédiaire ^^


Effectivement je suis tout à fait d'accord avec toi, l'ajout de champs pour une évolutivité n'est pas forcément la meilleure chose à faire. Après, c'est vrai que je cherche aussi les meilleures performances pour l'applicatif. A terme, il y aura environ 300 formules. Donc avec la solution 2 (qui n'est pas bonne conceptuellement), je peux en 1 seule requête sortir les formules ainsi que les valeurs des différente spécificités alors que dans la solution 1, si je ne me trompe pas , il va me falloir 300 requêtes (1 pour la sélection de toutes les formules + 300 x requêtes de sélection des valeurs de spécificité pour chaque formule) pour tout sélectionner...

Mais effectivement la gestion est bcp plus contraignante avec la solution 2 !

Concernant, les spécificités et sous-spécificités, je vais gérer ça avec la représentation intervallaire.

Voici un extrait de ce que je souhaite réaliser à terme. Bien sur il y aura beaucoup plus de lignes et de colonnes :-)

[Richard_35]

... dans la solution 1, si je ne me trompe pas , il va me falloir 300 requêtes (1 pour la sélection de toutes les formules + 300 x requêtes de sélection des valeurs de spécificité pour chaque formule) pour tout sélectionner...

==> je n'ai pas compris. Mais, non, il ne faudra pas 300 requêtes. Il ne sera pas nécessaire d'avoir autant de requêtes que de formules. Attendons, la suite de l'analyse, pour voir.


D'autre part, d'après ton exemple, il semble qu'il y ait des valeurs pour la famille (hospitalisation, optique, ...) et des valeurs pour les sous-familles (hospitalisation/frais de séjour, ..., optique/Année 2 et année 3), ...). Est-ce exact ?

[piieerre]

==> je n'ai pas compris. Mais, non, il ne faudra pas 300 requêtes. Il ne sera pas nécessaire d'avoir autant de requêtes que de formules. Attendons, la suite de l'analyse, pour voir.

Alors comment faire pour récupérer la liste des valeurs des spécificités de chaque formules ?

D'autre part, d'après ton exemple, il semble qu'il y ait des valeurs pour la famille (hospitalisation, optique, ...) et des valeurs pour les sous-familles (hospitalisation/frais de séjour, ..., optique/Année 2 et année 3), ...). Est-ce exact ?

Oui c'est bien ça

[Richard_35]

==> je n'ai pas compris. Mais, non, il ne faudra pas 300 requêtes. Il ne sera pas nécessaire d'avoir autant de requêtes que de formules. Attendons, la suite de l'analyse, pour voir.

Alors comment faire pour récupérer la liste des valeurs des spécificités de chaque formules ?

==> une clause WHERE dynamique (paramétrable).

D'autre part, d'après ton exemple, il semble qu'il y ait des valeurs pour la famille (hospitalisation, optique, ...) et des valeurs pour les sous-familles (hospitalisation/frais de séjour, ..., optique/Année 2 et année 3), ...). Est-ce exact ?

Oui c'est bien ça

Que penses-tu de ce premier jet (format JMerise) :

[SQLpro]

Famille contenir sous famille est idiot... En effet, quelle différence fonctionnelle faites vous entre les deux ?

Si oui (aucun traitement comment, ni même interrogations similaires) alors OK
Si non, alors une seule entitée avec bouclage en auto référence

Si en sus il y a des sous famille de sous familles, alors c'était une erreur !

A +

[Richard_35]

Bonjour SQLpro,

Famille contenir sous famille est idiot...

==> hum... sur la forme, restons modérés...

Sur le fond, juste pour poser les bases, il apparaît qu'il existe des sous-familles (trait bleu) liées à des familles (trait rouge). Les termes ne sont peut-être pas très appropriés.




La pertinence d'une entité unique avec association réflexive dépend, également, des attributs des sous-familles :

• si les sous-familles possèdent des attributs propres différents des attributs des familles, alors l'entité unique n'est pas pertinente ;
• si les sous-familles possèdent exactement les mêmes attributs que les familles, alors l'entité unique est pertinente.

Seul Piieerre possède les billes nécessaires...