Discussion :

[Dendrite]

Bonjour,

J'ai une base et une table famille.
Dans cette table où je stocke tous les membres de la famille du client, j'ai un champ lien_parente, qui est un enum('conjoint','enfant','autre')...
Et un champ demande_id...
Voici mon problème, ma clé d'uncité se compose actuellement comme suit

demande_id + lien_parente + nom + prenom

Or, j'ai le cas particulier suivant

Si et seulement si lien_parente="conjoint" alors uncité sur lien_parente+demande_id (la polygamie étant interdite en France)...

Si vous pouvez m'aider, si seulement c'est possible d'ailleurs ?

[escartefigue]

Bonjour,

Votre table de liens est mal construite

Une parenté se construit par une double relation reflexive sur la table des personnes, une relation parent (a pour parent) une relation enfant (a pour enfant)
La table issue de cette relation a donc deux identifiants de personne : l'identifiant du parent et l'identifiant de l'enfant et éventuellement des attributs supplémentaires (date de début par exemple pour les cas d'adoption)

L'unicité ne doit en aucun cas porter sur nom+prénom. Déjà, le plus souvent, tous les enfants portent le même nom de famille c'est donc un critère peu discriminant, de plus, le premier prénom peut parfois être identique dans une fratrie (rien ne l'interdit, ex : pierre, alain, marcel pour l'ainé, pierre, rené, tartempion pour le cadet)
Il existe des cas, rares certes mais qu'on ne peut négliger, où deux jumeaux (même nom, même 1er prénom et même date de naissance, même n° de sécu car mineurs et donc sous celui d'un des parents) ne peuvent être distingués que par le rang de naissance !
J'ai vécu ce cas très particulier lors de convergence de S.I. c'est marginal, mais ça existe.

Enfin que représente l'attribut demande_id ?
De base je ne vois pas le rapport avec la polygamie ? si monsieur Dupont et Mme Dupont née Martin, mariés, font deux demandes, ce n'est pas pour autant qu'ils sont polygames... (sauf s'il s'agit de demandes en mariage )

[Dendrite]

La table famille est bien comme elle est et suffit à ce qu'elle fait.
Elle ne sert ici qu'à produire un PDF statique.
La personne fait une demande, elle peut faire n demandes sur quelques années, auquel cas elle ne change pas de personne_id (tables en amont) mais elle change de demande_id. D'où l'idée qu'à une demande précis un jour précis, on a qu'un conjoint précis.

La question reste : peut-on mettre une clé d'unicité avec des if dans mysql, dont un if dépend de la valeur d'un champ, else... blablabla

Peut-être faut-il que j'impose un trigger plutôt ? du style "if new.lien_parente="conjoint" and demande_id=new.demande_id then update blablabla "?

[al1_24]

Un trigger sera plus adapté à traiter ce cas particulier.

[Dendrite]

Merci bien.

[Artemus24]

Salut à tous.

Je rejoins l'idée d'Escartefigue, à savoir que votre table est mal construite.
Le déclencheur ne va rien résoudre du tout, car si votre table est mal construite, automatisez un traitement ne va pas résoudre votre problème de modélisation.

Dans votre table famille qui contient des personnes, vous devez créer deux clefs étrangères admettant le NULL.
Pourquoi le NULL ? Vous n'allez tout de même pas remonter jusqu'à ADAM et EVE. De ce fait, vous aurez nécessairement un point de départ qui n'aura pas d'ascendance.
L'une des clefs étrangère sera pour le père et l'autre clef étrangère pour la mère.
Je sais maintenant on dit premier parent et second parent.

De ce fait, la clef primaire est nécessairement une clef technique, genre auto incrémenté qui rendra chaque personne unique.
La clef étrangère, qui se trouve dans la même table, pointera sur la clef primaire.

Pour rendre unique, vos clefs étrangères doivent être dans un index unique.
Le lien de parenté reste une notion qui devra être définie clairement.
Il faudra faire la distinction entre le parent biologique, et le parent par filiation.
Comme par exemple une adoption dans le cas du décès des deux parents dans une même famille.

Le cas de la polygamie est une chose, le remariage en est une autre.
Et rien n'empêche qu'une personne se remarie avec sa première épouse, suite au divorce d'avec sa seconde épouse.
Dans ce cas, vous pouvez introduire un rang pouvant signifier premier mariage, deuxième mariage, ...

@+

[Michel.Priori]

De ce fait, la clef primaire est nécessairement une clef technique, genre auto incrémenté qui rendra chaque personne unique.

Non ce n'est pas "nécessaire" mais très fortement conseillé.
Les clés signifiantes posent toujours des problèmes, au moins tout de suite avec les mises à jour d'informations, puis dans le temps avec le changement de "modèle".
Visiblement votre modèle s'appuie sur le modèle familial ; Avez-vous l'autorisation de la CNIL de stocker les informations du mode vie de vos abonnés ?

Bref séparez les demandes (date, options, ...) de la population (nom, prénom, ...) relevant de la demande en utilisant une clé de jointure arbitraire la plus légère possible.

[Dendrite]

Bonjour,

Avez-vous l'autorisation de la CNIL de stocker les informations du mode vie de vos abonnés ?

Oui, j'ai tout ce qu'il faut. Mais c'est normal et sain de poser la question, mais ce ne sont pas des abonnés, juste des demandeurs sociaux.
L'appli est utilisée par des assistantes sociales (qui ont le secret professionnel bien entendu) et les aide simplement à calculer un reste à vivre en fonction des déclarations du demandeur.
Comprenez-donc que je ne veux pas remonter les liens familiaux, nous ne parlons pas de généalogie.
A un moment M, celui de la demande, on calcule le reste à vivre par personne et par jour dans le foyer du demandeur.
Pour cela, il faut à un moment m, avec le demande_id, stocker dans la table famille
demande_id + lien_parente + nom + prenom

De façon à pouvoir lancer le nombre de membres du foyer au moment de la demande. C'est tout...
lien_parente étant la relation avec le demandeur : un enum ('conjoint','enfant','autre')

Je crois que c'est plus clair.
J'ai fini par résoudre mon problème en PHP ceci dit... pas très grave.
Si conjoint alors un seul couple demande_id + conjoint, sinon, tout est permis.

[SQLpro]

Encore une application avec des données personnelles sous MySQL et en PHP qui va conduire la CNIL a une bonne amende avec ce SGBD passoire au niveau de la sécurité.... !

En gros l'argument de défense de l’hôpital en question était "j'ai utilisé un outil de merde qui n'est pas capable de gérer correctement la sécurité des accès, donc je suis pas coupable...." Sidérant !

A +

[Michel.Priori]

Encore une application avec des données personnelles sous MySQL et en PHP qui va conduire la CNIL a une bonne amende avec ce SGBD passoire au niveau de la sécurité.... !

Salut SQLpro,
Ton aversion pour MySQL est notoire.
Je te remercie pour le lien car il est instructif.

Pour autant l'aspect sécuritaire sanctionné est l’écart entre le nombre de patient et le nombre de compte existant.
En quoi le modèle de sécurité de MySQL est en faute ?
Si le boulot d'admin n'est pas fait ce n'est pas la faute de l'outil !
On aurait eut le même problème avec SQL server que les comptes soient des connexions SQL ou des groupes de sécurité du domaine, si l'administration est mal faite... pas de miracle.

De plus, quelle est la responsabilité de PHP que t'as relevé dans cette affaire ?

@Dendrite :
Il va y avoir quelques digressions à votre post.
Désolé.
Dès que vous le sentez, remettez VOTRE demande actualisée au sein de la conversation.