Discussion :

[Invité]

Bonjour à tous,

Je dispose d'une base de donnée MySQL dand laquelle j'ai une table personne dont la structure ressemble à ceci :



Que je remplis à l'aide d'un tableau de tableaux qui ressemble à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Array
(
    [0] => Array
        (
            [0] => 147054261234567
            [1] => DURAND
            [2] => Pierre
            [3] => 1980-01-12
        )
 
    [1] => Array
        (
            [0] => 510893812345678
            [1] => DUPOND
            [2] => Anne
            [3] => 1958-10-12
        )
 
    [2] => Array
        (
            [0] => 519906987451895
            [1] => MARTIN
            [2] => Jacques
            [3] => 1991-01-14
)

Via ce script PHP :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
connexionBdd();
 
 // Insertion des données dans la table
foreach ($valeursExtraites as $valeurs) {
 
    $ligne = "'".implode("','",$valeurs)."'\n";
 
    $requete = mysql_query('
 
        INSERT INTO `maBase`.`maTable` (
            `pers_NNI` ,
            `pers_nom` ,
            `pers_prenom` ,
            `pers_dateGm` 
                                        )
        VALUES (
            '.$ligne.'
               );'
                          );
 
        if(!$requete) die ('Erreur dans la requete : ' . mysql_error());
}
mysql_close();

Cela fonctionne bien, mais :

• si une entrée existe déjà dans la table, j'aimerai qu'elle ne soit pas insérée
  --> SAUF dans le cas où seule la date diffère dans ce cas il faudra mettre à jour la date.
  
• 2 personnes différentes peuvent avoir : pers_NNI identique en ayant pers_nom, pers_prenom et/ou pers_dateGm différents.

Je ne peux donc pas mettre pers_NNI en clef primaire. Je dois gérer les homonymes.
En fait, le seul "couple" unique est : pers_NNI ET pers_nom ET pers_pernom

Je n'y arrive pas, quelqu'un pourrait-il m'aider ?

[sabotage]

Fais un SELECT avant pour voir si ta ligne existe déjà et en fonction du résultat fait un INSERT ou un UPDATE.

[SmokingBird]

dans ton insertion, ajoute la clause 'on duplicate key update' avec en paramètre "date='$date'", la clef étant par exemple le nom de la personne avec son prénom^^ (pas regardé le détail de ton code).

Donc, avant insertion, ça vérifiera si la clef existe déjà, donc l'entrée, identifiée par nom+prenom (dans l'hypothèse actuelle). Si la clef n'existe pas, ça insère, si elle existe, ça ne fait qu'updater la date. Ajoute d'autres champs dans la dernière clause si tu ne veux pas qu'updater la date.

en ce qui me concerne, je met ça dans toutes mes requêtes.

[Invité]

Merci pour vos réponses.

ON DUPLICATE KEY UPDATE semblait allechante mais la documentation MySQL indique que la clef spécifiée dans la clause doit être UNIQUE ou PRIMAIRE :

If you specify ON DUPLICATE KEY UPDATE, and a row is inserted that would cause a duplicate value in a UNIQUE index or PRIMARY KEY, an UPDATE of the old row is performed

Comme je l'ai dit, je ne peux mettre aucune de mes clef en unique ou en primaire.

Je vais donc opter pour la solution de sabotage.

Sujet résolu, merci pour vos réponses

[RunCodePhp]

Salut

Je ne peux donc pas mettre pers_NNI en clef primaire. Je dois gérer les homonymes.

Je ne vois pas en pourquoi une homonyme empêcherait d'avoir une clé primaire.

Sauf erreur, une homonyme veut dire qu'il y a une similitude, comme avoir 2 fois le même nom, prénom voir même la même date de naissance, mais ça ne veut pas dire que c'est la même personne.


Je dirais même que c'est tout l'inverse, c'est à cause du problème d'homonyme qu'il faut garantir l'unicité de chaque lignes en créant une clé primaire (une ID unique).

Une personne est unique, il ne peu en avoir 2, non (homonyme ou pas) ?
Ou alors il y a un truc que je ne pige pas.

[Invité]

on dit un homonyme

Non non rien à voir, je me suis mal exprimé. Les deux phrases ne sont pas liées entre elles. Je voulais dire

Je ne peux donc pas mettre pers_NNI en clef primaire. D'autre part, je dois gérer les homonymes.

Ce qu'il fallait comprendre, c'est que pers_NNI n'est pas unique : deux personnes peuvent avoir le même numéro de sécurité sociale (le cas des enfants assurés par leur parents) voire le même numéro de sécu ET la même date de naissance (cas des jumeaux ayant le numéro de sécu d'un des parents).

Quand je disais que je devais gérer les homonymes, c'était pour dire que je ne pouvais mettre les champs nom ou prenom en UNIQUE ou PRIMAIRE

[RunCodePhp]

Ce qu'il fallait comprendre, c'est que pers_NNI n'est pas unique : deux personnes peuvent avoir le même numéro de sécurité sociale (le cas des enfants assurés par leur parents) voire le même numéro de sécu ET la même date de naissance (jumelles ayant le numéro de sécu d'un des parents).

Ok.
Mais n'empêche que que le nom, le prénom et la date de naissance d'une ligne correspond à mon sens à une seule et unique personne, non ?
Donc même si ce N° qu'il y a dans ce champ "pers_NNI" correspond à 2 personnes, il y a un truc pas clair quand même dans cette table.

Comme ça, vite fait, je me dis qu'il y a des trucs qui n'auraient pas leur place dans cette table.

[Invité]

Là encore je me suis mal exprimé (décidement)

[...]deux personnes peuvent avoir le même numéro de sécurité sociale (le cas des enfants assurés par leur parents) voire le même numéro de sécu ET la même date de naissance[...]

C'était un exemple, je n'ai jamais dit que pers_dateGM correspondait à une date de naissance.

Je doit rester discret sur ce point. Mais en gros, la date est une date supposée qui pourra être réajustée une ou plusieurs fois via une mise à jour.

Sinon effectivement, le nom, le prénom et la date de naissance correspondent à une seule personne unique.

Dans mon cas, j'identifie une personne unique via le couple : numéro de sécurité sociale, nom et prénom.

[RunCodePhp]

Sinon effectivement, le nom, le prénom et la date de naissance correspondent à une seule personne unique.

Dans mon cas, j'identifie une personne unique via le couple : numéro de sécurité sociale, nom et prénom.

Et bien je m'en doutais bien, et c'est cela qui me parais pas correcte.
Dans le cas où il y a plusieurs fois la même valeur de "pers_NNI", les nom, prénom, etc ... sont aussi répétés, dupliqués, ce qui s'appelle de la redondance, et c'est ça qui normalement ne serait pas correcte.


Normalement, il ne faudrait pas avoir le nom, prénom et pers_dateGM (peu importe sa signification) dans cette table où il y a le champ "pers_NNI" qui lui, n'est pas unique d'après tes explications.

Comme ça, en pure exemple : (en admettant que le pers_NNI soit le N° de sécu)
(table) secu_soc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
pers_NNI | pers_id
123456789| 1
123456789| 2
987654321| 3
... etc ...

Ici, pour garantir l'unicité ici, suffirait de créer une clé primaire double :
PRIMARY KEY (pers_NNI, pers_id)


(table) personne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
pers_id | nom | prenom
 1      | nom_1 | prenom_1
 2      | nom_2 | prenom_2
 3      | nom_3 | prenom_3
... etc ...

Ici, pers_id serait une clé primaire (auto_incremente)


Au bout, plus l'ombre d'un problème d'homonyme ou d'unicité, on peu en avoir autant qu'on veut car à juste titre, l'unicité de la personne est garantie par la clé primaire (à condition que son code se base sur celle ci).

Pour récupérer (éventuellement) toutes les personnes liées à 1 N° de "pers_NNI", suffirait de faire une jointure sur les 2 tables grâce au champ "pers_id".


Je dirais même que pour éviter d'avoir 2 fois le même N° "pers_NNI" (N° de sécu) par erreur, les avoir dans une table séparés serait pas mal.
(table) numero_secu

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
pers_NNI | cree_le
123456789 | 2010-07-15
987654321 | 2010-07-15

Le champ "pers_NNI" comme clé primaire.


Tout ceci ne sont que des suggestions.

[Invité]

Edifiant

C'est vrai que dans l'absolu, ma structure ne guarantit pas l'unicité.

En effet je partais du principe que deux homonymes ne peuvent pas avoir le même numéro de sécurité sociale : en temps normal ça ne suffit pas, mais dans mon cas, c'est plus restrictif (les personnes sont des femmes enceintes uniquement, agées entre 12 et 76 ans)

Le cas qui génèrerait un doublon seraient donc :

1. Une femme enceinte, portant le même numéro de sécu qu'une soeur homonyme qui serait elle même enceinte et accouchant le même jour (dateGm)
2. Une femme enceinte, portant le même numéro de sécu que sa mère homonyme qui serait elle même enceinte et accouchant le même jour (dateGm)

Ca n'arrive (théoriquement) jamais.

Mais pour des raisons de conscience professionnelle et pour m'habituer à organiser convenablement mes données dans mes BDD, je vais mettre en place ta suggestion

Merci beaucoup pour tes explications.

[RunCodePhp]

Mon but n'était pas de te faire fracasser ta Bdd, mais juste faire des suggestions.
Si tu y vois là des trucs qui s'y prêtent, alors tant mieux.

Disons que les problèmes de conceptions de Bdd sont des trucs que j'aime bien, de plus, j'en fait pas beaucoup, alors ça m'exerce.


Sinon, là j'y connais franchement rien en N° Sécu, c'est donc par pure curiosité ici.
Mais ces numéros peuvent ils vraiment être identiques ?
Il me semblait qu'il y avait une série de quelques chiffres (2 ou 3) qui permettait de garantir l'unicité à cause de ces fameux homonymes.
M'enfin, si tu le dis, j'en doute pas, disons que je suis étonné.
C'est à croire qu'à l'époque ils n'avaient pas pensé à tout, et c'est l'bord** maintenant.
Ca me fait pensé aux adresse IP (IPV4 / IPV6).



Pour revenir au N° sécu, et là je ne sais même plus (bouuuuhh ... pas bien), est ce que c'est uniquement des chiffres (nombre entier) (une vrai certitude) ou alors il peu avoir des lettres, même 1 seule ?
En faite, je viens de remarqué que tu as mis comme type un VARCHAR au "pers_NNI".
Si c'est un nombre entier, un INT (le_nombre_de_chiffres) serait plus adapté.
Sinon, un CHAR (le_nombre_de_caractère) serait mieux aussi, car normalement c'est toujours le même nombre de caractères qu'il doit avoir (enfin, si je dis pas de bêtises) ...
Et je ne sais même pas le nombre de caractères qu'il y a. (c'est vraiment la honte )

[Invité]

Sinon, là j'y connais franchement rien en N° Sécu, c'est donc par pure curiosité ici.
Mais ces numéros peuvent ils vraiment être identiques ?
Il me semblait qu'il y avait une série de quelques chiffres (2 ou 3) qui permettait de garantir l'unicité à cause de ces fameux homonymes.

Le numéro de sécurité sociale ou NIR (là où je bosse, on a conservé l'ancien nom : NNI pour Numéro National Interne). C'est un numéro personnel, unique attribué par l'Insee.

Il est utilisé pour pas mal d'usages par les administrations, aujourd'hui ça ne choque plus parce que c'est contrôlé par la CNIL mais au début, ça a foutu un sacré bordel : ça faisait surtout peur gens d'être identifiés par un numéro unique. C'est même la raison de la création de la CNIL. Je te laisse regarder les articles sur Wikipedia c'est assez intéressant

Son format est le suivant (exemple) :


2 81 07 75 073 004 83

• Le sexe : 1 pour masculin, 2 pour féminin
• L'année de naissance (2 derniers chiffres)
• Le mois de naissance
• Le numéro du département de naissance
• Le code Insee de la commune de naissance
• Un n° d'ordre
• La (fameuse) clef de contrôle

En fait avec peu d'info sur une personne, on peu presque avori son numéro de Sécu (l'ordre peut surement se trouver dans les registre des mairies par exemple, puisqu'il sagit de la Nieme entrée du moi dans le registre). La clef est déjà plus difficile à deviner

La structure de ce numéro est sensée garantir l'unicité sauf pour les personnes nées le même jour à 100 ans d'écart, dans le même lieu (puisqu'on ne conserve que les 2 derniers chiffres de l'année de naissance).

En général, quand on a pas encore sa propre mutuelle, on possède le numéro de sécurité sociale d'un de ses parents, d'où le risque de doublon.

M'enfin, si tu le dis, j'en doute pas, disons que je suis étonné.
C'est à croire qu'à l'époque ils n'avaient pas pensé à tout, et c'est l'bord** maintenant.
Ca me fait pensé aux adresse IP (IPV4 / IPV6).

Oui je suis sûr à 100%. Mon application ne se destine qu'aux femmes enceintes, le seul risque de doublon, ça serait comme je l'ai dis :
qu'une jeune fille qui porte le même nom et le même prénom que sa tutrice (encore assurée sous la mutuelle de sa tutrice donc même N° de sécu) tombe enceinte et ayant la même date d'accouchement.
J'ai oublié de dire que mon application est limitée à un département, voire si jamais elle évolue, à une région. Ce qui limite encore le risque de doublon.



Concernant le typage je n'ai pas affiché la taille maximale attribuée à mes champs, mais voici où j'en suis actuellement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
pers_NNI char(15)
pers_nom varchar(40)
pers_prenom varchar(40) 
pers_dateGm date

Ca va me permettre de sortir du HS et de relancer une question technique :

Au niveau optimisation sachant que je n'effectue aucun traitement sur pers_NNI quel serait le meilleur choix ?

• VARCHAR(15) ou CHAR(15) : je suis passé du varchar(15) au char(15) puisque la taille est fixe, le varchar n'a pas d'interêt ici
• INT(15) ou TINYINT(15) : je sais qu'un INT permet le stockage de nombres plus importants que TINYINT mais lorsqu'on leur fixe la même taille limite, ça change quoi ?

[RunCodePhp]

Merci pour toutes ces infos sur le N° sécu (entre autre).
Vais devenir incollable


Pour ce qui est de l'optimisation, là, je ne pourrais rien garantir ou affirmer.

Disons que de mon coté, si c'est un nombre numérique, j'utilise un des types (INT, TINIYINT, etc ...).
Il me semble avoir lu que les type CHAR ou VARCHAR seront automatiquement plus gros (plus d'octets) que les type integer, car il y aurait 1 octet de plus (à longueur égale).

Aussi, il me semble avoir lu que pour une clé primaire, un type integer serait aussi plus rapide.

Mise à part ça, tu ne pourra pas utiliser un TINYINT, car sa longueur ne dépassera pas -127 127 (vraiment trop petit).
Même un INT ne passerait pas : -2147483648 2147483648
Ce serait théoriquement un BIGINT : -9223372036854775808 9223372036854775808, et il ferait 8 octets.
Théoriquement, un CHAR (15) ferait 15 octets (le double d'un bigint).
La doc : http://dev.mysql.com/doc/refman/5.0/...ric-types.html


Tout ceci sous réserve donc.

[Petibidon]

J'ai lu en travers donc je sais pas si ça a été précisé, mais une clé peut porter sur plusieurs champs, donc englober l'ensemble N° secu, nom et prénom.

De mémoire un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE machin ADD UNIQUE nomDeLaCle (champ1, champ2 ... champN)

[Invité]

Merci pour toutes ces infos sur le N° sécu (entre autre).
Vais devenir incollable

C'est le but du forum : échanger

Disons que de mon coté, si c'est un nombre numérique, j'utilise un des types (INT, TINIYINT, etc ...).

C'est la logique que j'essaie d'utiliser aussi

Mise à part ça, tu ne pourra pas utiliser un TINYINT, car sa longueur ne dépassera pas -127 127 (vraiment trop petit).
Même un INT ne passerait pas : -2147483648 2147483648
Ce serait théoriquement un BIGINT : -9223372036854775808 9223372036854775808, et il ferait 8 octets.
Théoriquement, un CHAR (15) ferait 15 octets (le double d'un bigint).

Oui je me rappelle de leur taille (j'ai vu ça en cours). Mais comme je ne manipule jamais je dis des bêtises. Dans mon post j'ai confondu la longueur maximum des chaines avec la taille maximale des type de valeurs numériques.

Bref je vais essayer avec un BIGINT pour voir ce que ça donne.

J'ai lu en travers donc je sais pas si ça a été précisé, mais une clé peut porter sur plusieurs champs, donc englober l'ensemble N° secu, nom et prénom.

De mémoire un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER TABLE machin ADD UNIQUE nomDeLaCle (champ1, champ2 ... champN)

Si c'est vrai ça serait super. Je me renseigne là dessus.


Merci à vous deux.

[RunCodePhp]

Si c'est vrai ça serait super. Je me renseigne là dessus.

Si même le cas est très rare (même N° de sécu, même nom, même prénom, même date), tu ne devrait pas pouvoir le faire théoriquement.

En faite, si on regarde bien, c'est qu'il te faut vérifier une chose et son contraire à la fois, et c'est ça qui est un peu la tuile.
D'un coté, la généralité (99,99% des cas) il ne faut pas que l'utilisateur entre 2 fois le même N° de sécu.
Mais de l'autre, cas rarissime, il faudra l'accepter.

Du coup, il serait peut être intéressant que ce cas rarissime vienne d'une action de l'utilisateur, et pour simplifier, pourquoi pas une case à cocher.
-> Jeune fille sous tutelle portant le même nom, même prénom etc ... : (case à cocher)

Avec ça, ceci permettrait de faire les bonnes vérifs une fois la création validée.
En gros :
1/ SI (sous tutelle cochée) ALORS :
On vérifie que le N° de sécu est présent -> sinon erreur
2/ SINON (sous entendu non cochée, cas général) ALORS
On vérifie que le N° de sécu n'existe pas -> sinon erreur.

Je simplifie ici, mais on peu tout à fait imaginer que si la personne coche la case (donc exception), faire un Ajax qui proposerait de rechercher la personne qui a autorité (celle à qui appartient le N° de sécu, l'autre personne quoi) afin d'anticiper, voir rajouter son "pers_id" dans le formulaire.
A la validation, on récupèrerait donc comme info que la case est cochée, mais le "pers_id" aussi, ce qui renforcerait les vérif plus haut.
Ici : SI coché ET PAS de pers_id ALORS erreur ...
Moins source d'erreurs, de duplication accidentelle au bout.


La encore c'est une idée

[SmokingBird]

Je confirme cette idée de clef possédant plusieurs champs. En fait, vu le niveau des intervenants je suis plutôt surpris qu'on n'en ai pas parlé plus tôt dans la discussion .

J'utilise moi même cette astuce pour mes BDD, quand il s'agit de gérer la relation entre certains éléments de mon site.

J'ai aussi lu en travers, mais ne serait il pas possible (toujours pour l'amour de la technique ), voir 'intéressant' (idée rapide), de proposer une clef basée sur un champ numéro de sécu et un champ jour de naissance? Voir même, mais peu orthodoxe et un peu cradot, un champ seul concaténant num sécu.jour_naissance.

Les conditions me paraissent déjà optimales pour éviter les doublons, mais j'ai remarqué qu'il manquait l'info jour de naissance dans le num de sécu, et je pense que ça peut être intéressant de l'exploiter^^ car si on partage le numéro de sécu de ses parents, c'est assez rare qu'on soit une femme, qui tombe enceinte, accouche le même jour que sa tutrice, et soit EN PLUS née le même jour


enfin j'dis ça, j'dis rien...

[RunCodePhp]

Je confirme cette idée de clef possédant plusieurs champs. En fait, vu le niveau des intervenants je suis plutôt surpris qu'on n'en ai pas parlé plus tôt dans la discussion .

J'utilise moi même cette astuce pour mes BDD, quand il s'agit de gérer la relation entre certains éléments de mon site.

La réponse tu la donne toi même : C'est une astuce
Par conséquent, ça ne respecte pas les normes, les règles de bonne conceptions d'une BDD.


Pourtant, les choses sont simples, tout est une question de relation 1-1 ou 1-n.
D'abord, une Bdd se doit de refléter la réalité.
Ici, la réalité c'est qu'on gère des personnes, donc une personne est unique, ça, on peu difficilement faire autrement.
Donc coté Bdd, il parait évident qu'on puisse attribuer un Identifiant unique à chaque personne.
Déjà là, dans son modèle ça ne va pas (pas d'ID).

Ensuite, il est dit que, fait très rare certes, mais c'est la réalité, que 2 personnes (peut être plus) peuvent avoir le même N° de sécu.
Coté Bdd, il y a une alors une relation 1-n, donc le N° de sécu ne doit pas se trouver dans la table "personne".
Si on faire les choses dans les règles, faut créer une table pour les N° sécu.
Et comme le N° de sécu est lié à une ou n personnes, dans celle ci on retrouve tout naturellement le couple : N° | Id_pers.
Ces 2 données sont la clé primaire, ce qui évite un doublon.

Ici, il y a strictement rien d'anormal, c'est le genre de chose qui se fait dans pleins de table, donc pourquoi vouloir chercher des astuces ?
A mon avis, on s'entête à vouloir que ce N° Sécu soit unique, et du coup ça débouche sur de fausses relations.


La relation que l'on évoque entre le N° de sécu et la date de naissance est à mon sens une pure invention de notre part, car si on regarde bien, il y en a aucune dans la réalité, sinon qu'un fait du hasard, pure coïncidence.
Si on commence à créer une Bdd avec des phénomènes hasardeux, ça risque d'être très compliqué.
Pour ma part, il n'y pas de relation à avoir entre le N° de sécu et la date de naissance, ces 2 données n'ont aucun rapport.

Enfin, c'est mon avis.