Discussion :

[socrate]

Bonjour

Je suis en train d'utiliser std::set pour gérer un ensemble de personnes. Disons que j'ai une classe personne avec un entier décrivant le numéro de téléphone. J'utilise ce numéro de téléphone comme clé pour comparer deux personnes dans l'ensemble (p1 < p2 <=> p1.tel < p2.tel). J'insère donc les personnes au fur et a mesure avec la méthode insert
Le problème survient lorsqu'une persone change de numéro de téléphone (je simplifie l'écriture)

Code :

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

1
2
3
 
iterator i=personnes.find(numéro);
if(i != personnes.end()) i->SetNuméro(nouveau_numéro);

Mais la bien sur la personne n'est plus au bon endoit dans l'ensemble.
Je voudrais donc savoir quelle est la meilleure solution selon vous:
-Continuer ainsi, mais en enlevant et en réinsérant l'objet à chaque fois
-Utiliser comme clé quelque chose qui ne change pas (mais ce n'est pas toujours possible...)

[Laurent Gomila]

S'il n'est pas possible d'avoir une clé constante alors tu n'as pas le choix, il faut retirer puis réinsérer l'élément.

[ash.ice.loky]

Salut,

Mais la bien sur la personne n'est plus au bon endoit dans l'ensemble.
Je voudrais donc savoir quelle est la meilleure solution selon vous:

-Continuer ainsi, mais en enlevant et en réinsérant l'objet à chaque fois

C'est une methode efficace si tu ne doit pas faire trop de changement.
Dans ton cas, la solution est viable car de tout maniere ton algo est constructif
et non iteratif, du coup tu effectueras cette operation ponctuellement et meme si elle est couteuse en ressource cela ne changeras rien a l'execution du programme.

-Utiliser comme clé quelque chose qui ne change pas (mais ce n'est pas toujours possible...)

La ca depend de toi, si tu veux un annuaire inverser, tu doit prendre le tel pour retrouver la personne correspondante. C'est sur que si tu prends son nom tu es tranquille (quoi que si elle se marie ou divorce) mais ce n'est plus la meme fonction du coup.

[koala01]

Salut,

L'*idéal*, c'est de gérer tes clés sur base d'une valeur absolument unique et qui ne risque pas de changer (numéro de sécu ou numéro de registre nationnal par exemple).

Meme un algorithme qui créerait un identifiant sur base du nom, du prénom et d'une date de naissance ne serait pas sécuritaire à 100%...

Ne riez pas: je connais une personne qui, s'étonnant de ne pas avoir recu sa déclaration d'impôts s'est entendu répondre "c'est normal, madame, vous êtes morte depuis deux ans"...

Simplement, il y avait deux homonymes, nées à la meme date, et ils s'étaient trompés lors du déces de l'une d'elle...

[socrate]

Merci pour toutes vos réponses.
En fait le problème est un peu le même que celui des clé primaires des bases de données si je comprends bien

[koala01]

Merci pour toutes vos réponses.
En fait le problème est un peu le même que celui des clé primaires des bases de données si je comprends bien

Exactement...

Finalement, ce que tu fais, c'est "simplement" "réinventer les bases de données"...

(pour rappel: une base de données n'est pas exclusivement informatique )

Maintenant, rien ne t'empeche, une fois que la personne est identifiée de manière unique et immuable, de créer des index sur les différents champs, mais tu seras toujours confronté au choix épineux entre quelque chose permettant la mise à jour rapide avec une faible redondance, mais une recherche "plus lente" et quelque chose présentant une forte redondance, permettant une recherche rapide mais ralentissant la mise à jour des données...