Un petit probleme d'enregistrement

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Un petit probleme d'enregistrement

par iclo » 23 déc. 2005, 14:43

Ce serait pourtant la seule façon propre de le faire, je suis perplexe devant ton refus d'utiliser des id, c'est pourtant la notion primoridiale des bases de données relationnelles.

par bins007 » 23 déc. 2005, 13:33

Oui j'ai compris mais je ne voudrais pas faire comme ça car il faudrais reprogrammer tout le site alors comment faire ?

par Cyrano » 22 déc. 2005, 21:58

Alors dans ce cas, tu peux ajouter en clé étrangère dans l'autre table un champ id_utilisateur dans laquelle tu retrouveras la clé primaire correspondant de la table utilisateur.

Est-ce que tu en saisis le principe et l'utilité ?

par bins007 » 22 déc. 2005, 21:53

Oups désolé j'ai oublié qu'il y'a un champ id aussi dans la premiere table qui est déjà en clé primaire alors je met le champ pseudo en unique ?

par Cyrano » 22 déc. 2005, 21:24

Alors dans les deux tables, passe le champ "pseudo" en clé primaire: ça interdira les doublons.

par bins007 » 22 déc. 2005, 21:01

Je n'ai pas trop compris ta réponse, ma question aussi etait mauvaise.

Voilà les exemples

table utilisateur : champ : pseudo, passe
table info_utilisateur : champ : pseudo, nom, prenom

Voilà aucun des champ n'est en clé primaire ou index ou meme unique.

Donc je voudrais résoudre le problème des pseudos identiques sans trop modifier la structure.

Et pour la relation entre les tables ma structure est elle bien ? car je ne veux pas utiliser les id (nombre) pour identifier chaque membre

par Cyrano » 22 déc. 2005, 20:53

Pour les relation entre les tables, on utilise les clés primaires, c'est d'ailleurs un de leur principaux intérêts. Avec ton histoire de pseudos proches les uns des autres, ce serait une raison de plus d'utiliser les clés primaires à la place.

par bins007 » 22 déc. 2005, 20:48

J'ai déjà fais ça mais apparement il pense que bébé et bebe sont différents lors du SELECT et pareil lors du UPDATE

en sachant que mon champ pseudo n'est pas unique, primaire ni index

J'ai une autre question lié :

En ce moment sur les autres tables lié à la table principale qui contient le pseudo du membre, j'utilise pour identifier le membre : le pseudo

Est ce que ça serait mieux d'utiliser un identifiant (nombre) ?

par Cyrano » 22 déc. 2005, 20:42

En mettant sur ce champ un index UNIQUE et en interdisant l'utilisation de ce pseudo s'il existe déjà dans la base: ça signifie que lors de l'inscription, tu vérifie d'abord dans la base si le pseudo choisi par le futur nouveau membre est disponible et ensuite seulement tu l'enregistre, sinon, tu demande d'en choisir un autre avec en bonus si tu te sens le courage de le programmer un système proposant des pseudos alternatifs.

Un petit probleme d'enregistrement

par bins007 » 22 déc. 2005, 20:34

Voilà je voudrais faire un script d'espace membre avec ma base SQL.

Donc l'enregistrement d'un membre est OK

Mais voilà le probleme, imaginons qu'un membre s'appelle bebe, l'autre bébé et un troisieme Bébe

Au moment d'un "UPDATE" la modification se fait sur les 3 personnes, comment résoudre ce problème ?