Champs identique + Fusion ID

BOnjour à tous,

Dans le cadre de mon stage dans une compagnie d'assurance, je dois effectuer un petit travail dans une table, je m'explique:

Pour mon test, j'ai créer un formulaire simple avec 3 champs [nom/prénom/email]
en pdo....

la consigne est la suivante: Lorsque une personne rentre un nom de famille, et un prenom identique à un nom et prénom existant, ce dernier doit recevoir le même ID....

Code:

---

1 2 3 4 5 6 7 8

Exemple : Table: test   ID Nom Prenom Email   1 toto tata aaa@aaa.com 2 mama mimi bbb@bbb.com 3 toto tata ccc@bbb.com

---

Au vue de l'exemple ci-dessus je voudrais que l'ID 3 reçois le 1 car même nom et prenom que l'ID 1

J'espère que j'ai été clair et que c'est compréhensible

Merci de vos réponses


COrdialement

Bonjour,
si (comme c'est généralement le cas) ID est un champ "index auto-incrémenté", ce n'est pas possible, car il doit rester unique.

1/ Une méthode permettant d'associer plusieurs email à un seul client :
faire 2 tables : les 2 tables sont liées via le champ "id_client".

Code:

---

1 2 3 4 5 6 7 8 9

table CLIENTS : id_client (int) auto-incrément, nom (varchar 150), prenom (varchar 150)   table EMAILS : id_email (int) auto-incrément, id_client (int), email (varchar 150)

---

2/ Sinon, avec une seule table : plusieurs champs "email1", "email2", "email3"

Code:

---

1 2 3 4 5 6 7

table CLIENTS : id_client (int) auto-incrément, nom (varchar 150), prenom (varchar 150), email1 (varchar 150), email2 (varchar 150), email3 (varchar 150)

---

3/ 3ème méthode, Lorsque une personne rentre un nom de famille, et un prenom identique à un nom et prénom existant :
Vérifier si ce couple nom/prenom existe déjà en Bdd, et mettre un message d'alerte :

Code:

---

"Oups ! Ces nom et prénom sont déjà enregistrés !"

---

Par définition, ton id doit être unique.

De plus pourquoi deux personnes ayant le même nom serait rassemblées sous un même identifiant ?

En faite la vrai table de la base de données se nomme Utilisateur....

un Utilisateur est un marin avec des dates d'entrée et de sorties
et le seul problème c'est que ce marin peut être modifié ou bien affecter sur un autre bateau.

Donc l'ID de ce dernier change alors qu'il ne faut pas car il est affecté à des assurances bien précise avec des ID propres.

Et si le marin change d'ID il devra être réaffecter aux mêmes assurances donc doublons

Oui Jreaux c'est ça qui me tracassais, c'est que le champs ID est en Auto-Incrément, si je le désactive et que je le met en unique je ne sais pas ce que ça donnerai =s

La bonne question est donc :
- ID est-il le champ "index auto-incrémenté" de la table ?,
- ou simplement un IDENTIFIANT du marin (comme un numéro de sécu, par exemple) ?
[EDIT] Oups, Tu as répondu en même temps (cf ci-dessus).

Non Non c'est bien un champ INDEX AUTO INCREMENTE

Citation:

---

Envoyé par corv0

... ce marin peut être modifié ou bien affecter sur un autre bateau.
Donc l'ID de ce dernier change alors qu'il ne faut pas car il est affecté à des assurances bien précise avec des ID propres....

---

On a ici une problématique de CONCEPTION des TABLES en BdD.

1/ la table "utilisateur"
LE MARIN : il est unique (!)
-> l'ID est unique aussi,
-> la table "utilisateur" ne doit contenir QUE des informations sur CE MARIN (noms, coordonnées, date de naissance, num de sécu,...)

3/ une table "BATEAU"
idem : que les infos sur CE BATEAU

Code:

---

1 2 3 4

table "BATEAU" : ID_bateau (auto-incrément => UNIQUE) nom_bateau ...

---

3/ Pour ses AFFECTATIONS => MISE EN RELATION des marins et des bateaux :
il faut créer une TABLE RELATIONNELLE :

Code:

---

1 2 3 4 5 6

table "AFFECTATIONS" : id_affectation (auto-incrément => UNIQUE) id_marin (ON PEUT AVOIR PLUSIEURS LIGNES AVEC CET id_marin !!) id_bateau (ON PEUT AVOIR PLUSIEURS LIGNES AVEC CET id_bateau !!) date_entree date_sortie

---

- UN marin => PLUSIEURS affectations
- UN bateau => PLUSIEURS affectations

On en revient à ce que te disais Jreaux : la même personne ne doit pas pouvoir s'inscrire deux fois.

Ton problème est maintenant dans la gestion et non plus dans le developpement : tu ne peux pas différencier avec les seuls éléments que tu nous as présenté, un marin qui veut s'inscrire deux fois avec deux emails différents, de deux marins avec le même nom.

La table Utilisateur contient justement tout ces champs....

Pour t'aider je t'envoi un petit screen de la table utilisateur =)


Pièce jointe 123922

Pièce jointe 123924

On a bien compris cette table.

Par contre, tu n'as pas compris la problématique (ou c'est nous ?!? :koi:)

Sois plus précis dans l'énoncé des "VRAIES consignes".
En évitant une "simplification extrême", qui ne fait qu'embrouiller.

Normalement, s'il s'agit d'AFFECTER un MARIN à un BATEAU :
1/ Formulaire :
- on met un <select> (liste déroulante) avec les nom/prénom pour sélectionner LE marin
- idem pour le bateau
- puis les autres <input> relatifs à CETTE affectation en particulier (date d'entrée, de sortie,...).

2/ Traitement :
- On récupère les données du formulaire : [id_marin + id_bateau + infos...] => les IDS suffisent alors à IDENTIFIER de façon UNIQUE les marin/bateau.
- On enregistre alors [ces infos + id_marin + id_bateau] dans la table que j'ai nommée : table "AFFECTATIONS"

Pour ça je suis exactement d'accord avec toi y'a aucun problème la dessus,

On va dire le marin à un id= id_uti : 20
Le problème est que lorsque un marin est sorti d'un bateau avec l'id 20,
il est possible de le réactivé et de le rentrer sur un autre bateau qui à pour effet de lui affecter un autre ID:

Ex id_uti : 20 est passer à id_uti:258

Et ça on veux pas =/

PS : Merci de prendre du temps pour me répondre

Justement non :
c'est l'intérêt de la table relationnelle "AFFECTATIONS".

Pour UN seul et même marin (donc un ID_marin unique), on peut avoir plusieurs affectations

L'ERREUR (ou la CONFUSION) que tu fais est de vouloir enregistrer la NOUVELLE AFFECTATION dans la table "utilisateur" !

Relis ce que j'ai écrit ci-dessus.

Voilà il faut faire en sorte de ne pas toucher a l'ID du marin et lors d'une affectation mettre ceci dans la table "affectation ou juste les infos et l'id du bateau change

C'est bien ça.

Et certains champs de la table "utilisateur" doivent être supprimés et mis dans la table "affectation".
Je pense par exemple à :
- mission_start_date
- mission_end_date

Bref, il faut revoir la CONCEPTION DES TABLES, et leurs RELATIONS.

Merci Beaucoup Jérome =)