Discussion :

[selmagsi]

Salut tout le monde...
je suis à la réalisation d'une application. Dans mon diagramme de classeq, j'ai la classe patient sportif qui hérite de la classe patient (non sportif).
Sur PostgreSQL, j'ai créé mes deux tables patient et patientSportif et je veux qu'on ne trouve jamais un code du patient sportif égal à un code du patient ordinaire. C'est-à-dire que la clé primaire code, je veux qu'elle soit commune entre les deux tables...
J'ai pensé à faire une table commune et autoriser les champs concernant le sportif à null, mais ça ne convient pas vraiment à mes besoins. Alors je veux deux tables avec une clé primaire.
Si c'est possible, informez-moi s'il vous plaît.
Merci d'avance

[sevyc64]

Bien que ne connaissant pas particulièrement Postgre, je ne pense pas que mettre une clé primaire répartie sur 2 tables (ou plus) puisse être possible.

A supposer même que seulement une règle d'unicité soit possible de la sorte, je pense que ça alourdirait pas mal la charge de travail du serveur.

Je pense que tu pars sur une mauvaise modélisation.

Soit tes tables Patient Sportif et Patient Non Sportif n'ont absolument rien en commun pour être dans des tables séparées, à ce moment là elles sont totalement indépendantes et vivent leur vie chacune de leur coté, soit elles beaucoup de points en commun (être des patients déjà), suffisamment pour que ces points en commun soient intégrés dans une table mère (une table Patient, voire une table Personne) dont les 2 hériteraient. Dans ce cas, la clé primaire de chaque table serait donc (héritage) une clé étrangère vers la primaire de la table mère. L'unicité se jouant alors ici directement dans la table mère.


A noter que, si seulement peu de différences sépare les 2 tables Patient non sportif et Patient sportif, elles peuvent être combiné en une seule table avec une info (champ de type booléan par exemple) différenciant le type de patient.

[selmagsi]

Merci beaucoup Yevs ...
Pour le patient sportif, il a trois attributs en plus par rapport à un patient ordinaire... Je dois gérer chacun indépendamment de l'autre. Je vais gérer un centre médical qui était dédié seulement aux sportifs ayant une activité au sein du stade principal de ma wilaya. Après, ils ont autorisé les consultations des citoyens n'ayant aucune activité sportive. Alors il y a certaines statistiques qui ne se font que sur les patients sportifs...
Je vais essayer de voir avec l'idée de la clé étrangère ,et j’espère m'y retrouver.

[sevyc64]

Ok, en retournant les choses :

- tu as une base existante de patients, considérés sportifs par défaut.
- tu rajoute maintenant des patients qui ne sont pas sportifs.
- ces patients n'ont que trois attributs en moins par rapports aux patients par défaut
- et, implicitement, un attribut en plus, ils ne sont pas sportifs.

Maintenant, les pistes à étudier :
- Concernant les 3 attributs, il faut voir si cela peut poser problème dans la totalité du logiciel, qu'ils ne soient pas renseignés (patients non sportifs)
- Concernant les stats et parties du programme, s'il est possible d'y apporter une modification enfin de prendre en compte (ou plutot ignorer ici) un certain nombre de patients selon un critère particulier, l'attribut "Non Sportif" justement.
- Voir si la base est modifiable.

Si tout cela ne pose pas de problème particulier, tu dois pouvoir utiliser la même table pour tous tes patients. Tu rajoute juste un champs, type bit/boolean/True-False, ... pour enregistrer l'information "Non Sportif" de tes patients.
Ensuite il faut reprendre le(s) logiciel(s) consommant ces données là pour que, là ou la liste des patient était utilisée, désormais c'est la liste des patients ou l'attribut "Non Sportif" est à Faux qui soit utilisée.


Maintenant, c'est toi qui a la problématique entre les mains, c'est toi qui connais la structure de tes données et de ton système, c'est à toi de voir si cette piste est convenable, ou s'il faut que tu passe par d'autres pistes (tables indépendantes, héritage avec clé étrangère, etc).

[selmagsi]

J'ai bien réfléchi à ce que vous m'avez proposé, et je vois l'idée du booleen true pour sportif et false pour non sportif très intéressante et je vais l'utiliser.
Je vous remercie beaucoup pour votre aide.
Cordialement

[ericd69]

salut,
pourquoi ne pas passer par l'héritage de table?

patients (tu y définis les données communes)
|
+-sportifs (tu y définis les données spécifiques en plus)

ça répondrait à ta problématique

tu as des exemples dans la doc postgreSQL pour gérer une table ville et une table capitale qui hérite d'elle.
l'avantage tu peux interroger la table globale (patients) ou seulement la table sportifs selon les besoins.

et oui tu peux utiliser une séquence commune aux 2 tables pour garantir l'unicité des identifiants.

[sevyc64]

C'est bien ce qui a été proposé, sachant que l'héritage ne se traduit pas forcément par des tables supplémentaires.

Par exemple, si l'héritier n'a que peu d'attributs en plus, ou que même n'a pas d'attribut supplémentaire, un simple champ indiquant son status d'héritier (ici "EstSportif") suffit dans la table d'origine

[ericd69]

je n'ai pas dit le contraire, j'ai juste rajouté la version implémentée dans postgreSQL vu que tu n'en parles pas vraiment... alors que ça existe en natif

après, c'est clair que ta solution est tout à fait un bon patch à son problème

[sevyc64]

Oui, je parlais en généralité, pas spécifiquement à un SGBD.

D'ailleurs comme je l'ai dit, je ne connais pas (bien) PostgreSQL