[RESOLU] Problème SQL.

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 : [RESOLU] Problème SQL.

Re: Problème SQL.

par niconicochan » 16 mars 2014, 17:51

PROBLEME RESOLU.

J'ai réglé mes problèmes, de loin surtout avec des idées puis du travail (en passant aussi par des révisions).
Il y a juste un truc que je n'ai pas encore bien compris, c'est ces histoires d'octects.
CHAR représente une chaîne de caractères de longueur fixe, mais
le nombre d'octects qu'on écrit entre parenthèses ça correspond à combien de caractères?
Tous les caractères prennent le même nombre d'octects?

Si vous me répondez à cette question ça m'avance, mais sinon c'est pas très grave, je comprendrai mieux
sûrement plus tard, au fil de mon apprentissage.
Merci pour tout.

Vos recommandations m'ont permis de comprendre plus de choses.
Même si j'ai trouvé la solution autrement elles m'auront été utiles. :D

Re: Problème SQL.

par niconicochan » 14 mars 2014, 19:38

Pour dire les choses sincèrement, j'ai appris 550 pages sur php et mysql.
Il se peut que des choses aient été mal assimilées.
En tout cas, je fais tout mon possible pour essayer de construire quelque chose de cohérent.
Soit alors j'ai un problème de connaissance (oublis) ou soit, peut-être plus probable,
j'ai un problème pour mettre en application de la théorie apprise.

Par rapport aux trois points évoqués:

1) nomutilisateur est un login choisi par une personne qui représente une société ou pas.
De mon côté, j'ai fait exprès de fixer 10 caractères pour ce champs choisis à l'origine
par l'utilisateur. Il doit choisir effectivement 10 caractères, pas 9 et pas 11 non plus.

2) Je sais qu'en France 5 chiffres suffisent pour un code postal.
J'ai fait exprès d'en mettre 15 ne me limitant pas à la France.

3)firmeouinon. Ca correspond à des choix d'options (radio) dans le formulaire.
Il y a deux valeurs au choix: value="firmeoui" ("oui" sur formulaire dans le navigateur de l'utilisateur)
et value="firmenon" ("non" sur formulaire dans le navigateur de l'utilisateur).
Je demande si l'utilisateur est une entreprise ou "un particulier".

Voilà, donc tout a été pensé.
Peut-être (et même sûrement puisque j'ai des problèmes) mal pensé, mal réfléchi.
Quoi qu'il en soit, phpmyadmin m'indique qu'il y a des erreurs de syntaxe et je n'arrive pas à
valider ma table.
Si vous pouvez m'indiquer ce qui peut clocher ça m'aiderait car je bloque.
Je vais aussi regarder le lien envoyé.
Si vous pouvez me donner une réponse quant à votre analyse d'autres éléments suspects
je prends tout de suite car même en bossant sérieusement dessus j'ai du mal...

Re: Problème SQL.

par damien_55 » 14 mars 2014, 14:57

bjr,

Je rebondis sur ce que je disais hier, si tu veux vraiment te mettre au mysql, il conviendrait de d'apprendre sur des tutos ou des bouquins. Ce n'est pas péjoratif, on est tous passer par là.

Toute action sur mysql et définition des types de données ont une action sur sa performance. Tes choix de types et de valeurs me font bondir :evil: , c'est tellement incohérent...

La doc http://dev.mysql.com/doc/refman/5.0/fr/ ... types.html

1/ nomutilisateur char(10) -> apparement, c'est pour des sociétés. je mets comme nom utilisateur, mon nom et prenom, je suis limité à 10 caracteres. ça ne rentre pas ! De plus, CHAR définit un nombre d'octets définis, pas variables. Donc si, on mets 10 et que la donnée entrée prends 4, ça comptera quand meme pour 10.

2/ codepostal bigint(15) NOT NULL utf8_general_ci,
il ne sert à rien de mettre bigint dans ton cas. Un code postal en france est au plus de 5 chiffres donc inutile gacher des octect pour ça.
Mets simplement int (5) ça suffira.

3/ firmeouinon text(3): Text, comme cela dit c'est du texte. (avec des paragraphes par exemple). Un nom de firme ou de société ne sera jamais un paragraphe ou un chapitre.

Bref, il y a tout à reprendre sur ce point.

Re: Problème SQL.

par xTG » 14 mars 2014, 14:17

J'en dis que l'erreur parle de la table registration et que tu nous montres la requête de création de la table inscription. :mrgreen:
A ma connaissance il n'y a pas encore de traducteur automatique dans Phpmyadmin. :P

Re: Problème SQL.

par niconicochan » 14 mars 2014, 13:55

J'ai réessayé de construire la table directement à partir phpmyadmin en local.

J'ai écrit:

CREATE TABLE 'inscription' (
nomutilisateur char(10) NOT NULL utf8_general_ci AUTO_INCREMENT PRIMARY KEY,
motdepasse char(8) NOT NULL utf8_general_ci,
firmeouinon text(3) NOT NULL binary utf8_general_ci,
nomfamille text(25) NOT NULL utf8_general_ci,
prenom text(25) NOT NULL utf8_general_ci,
sexe text(5) utf8_general_ci,
age char(3) utf8_general_ci,
adresseemail varchar(35) NOT NULL utf8_general_ci,
numerotelephone varchar(15) utf8_general_ci UNSIGNED,
numeromobile varchar(15) utf8_general_ci UNSIGNED,
numerorue char(3) NOT NULL utf8_general_ci,
nomrue text(100) NOT NULL utf8_general_ci UNSIGNED,
codepostal bigint(15) NOT NULL utf8_general_ci,
ville text(25) NOT NULL utf8_general_ci UNSIGNED,
pays text(25) NOT NULL default'France' utf8_general_ci,
);

On me répond:

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''registration' ( login char(10) NOT NULL utf8_general_ci AUTO_INCREMENT PRIMARY' at line 1

Qu'est-ce que vous en dites?

Re: Problème SQL.

par niconicochan » 14 mars 2014, 00:09

Merci à vous deux pour votre aide.
Ça commence à aller mieux, je vais réessayer tout seul demain
Avec ce que vous m'avez dit dans un premier temps.

Merci Sirakawa pour la précision, je n'avais pas compris.
A vrai dire, je n'ai jamais fait passé par l'étape CREATE table à partir d'un script PHP,
mais à partir de phpmyadmin en cliquant sur l'icône SQL.
Ça doit revenir au même (ça marchait d'ailleurs très bien quand j'avais des tables hébergées)
mais je n'écris effectivement pas de script pour cette étape.
Sur phpmyadmin en local, j'ai cliqué sur un bouton créer une bd à laquelle j'ai donné un nom,
puis sur un bouton créer une table à laquelle j'ai donné un autre nom.
Mais je ne suis pas passé par le bouton SQL dans phpmyadmin pour écrire
CREATE table à la main, et du coup j'ai complètement oublié que je faisais comme
ça avant. Je vais tout d'abord "refaire des révisions sur ce point" dans un premier temps
faire des corrections si nécessaire. J'ai peu être zappé une étape clef.

J'ai l'impression de comprendre ce que je fais quand je crée ma base, ce qui est différent de vraiment
comprendre je suis d'accord. Mais je ne veux jamais faire quoi que ce soit au hasard.

Quand aux questions de Damien:

1) Pourquoi un mot de passe en clef primaire? En effet, plus je repense à cette question,
plus je trouve ça moi-même incohérent. J'ai d'abord trouvé nomutilisateur très bien comme clef primaire
(et je trouve toujours ça très bien) et alors je me suis dit que deux utilisateurs peuvent avoir un même
nom d'utilisateur du fait d'un mauvais hasard, j'ai donc décidé de coupler cette clef primaire avec une
autre clef primaire, et j'ai pensé simplement à ce que l'utilisateur rentre après son nom d'utilisateur:
son mot de passe.

2) J'ai appris SERIAL dans php et MySQL pour les nuls. SERIAL comprend AUTO_INCREMENT, ce dont je vais
avoir besoin. Je sais qu'on peut choisir AUTO_INCREMENT dans une liste déroulante lorsqu'on crée une table
dans phpmyadmin hébergé chez OVH, donc je pense que ça doit être possible aussi sur phpmyadmin en local.
Si vous savez comment on fait ça m'intéresse

3) codepostal CHAR 15 unsigned. Tu veux dire que comme en gros unsigned va multiplier par 2 ma capacité de stockage,
c'est contradictoire avec une valeur fixe dont le nombre maximum de caractères est figé (ici à15 caractères).

4) je ne pensais pas que les noms de rues pouvaient être si longs. Bon, je vais mettre nomrue TEXT 100 pour
prendre large.

Quand à la présence du CHA dont parle Sirakawa, je vais regarder ça à nouveau.

Merci déjà pour tout ça. Ça me permet d'avancer.

Re: Problème SQL.

par damien_55 » 13 mars 2014, 21:12

Bonjour,

Quand tu crées ta base, tu comprends ce que tu fais ou tu as juste fais un copié collé ?

J'ai du mal a comprendre:

1/ nomutilisateur SERIAL 10 Aucune UTF8_general_ci Primary
motdepasse SERIAL 8 Aucune UTF8_general_ci Primary ??

pourquoi mettre un mot de passe en clef primaire ??

2/ SERIAL, je l'ai vu dans le progresql, mais pas en mysql. D'ailleurs si tu regardes sur une création de table, je crois que ce type de donnée n'est pas proposée.

3/ codepostal CHAR 15 Aucune UTF8_general_ci unsigned : pourquoi mettre unsigned ?? unsigned va te changer la capacité de stockage. D'ailleurs a verifier si c'est vraiment compatible avec CHAR. pour des codes postaux INT ou BigINT suffit (BIGINT stocke les nombres entiers entre -9 223 372 036 854 775 808 à 9 223 372 036 854 775 807)

4/ nomrue TEXT 25: Seulement 25 caracteres pour un nom de rue. Mon adresse ne rente pas par exemple. pas top pour l'utilisateur.



Bref, je ne vois pas la logique de cette table.

Re: Problème SQL.

par sirakawa » 13 mars 2014, 21:02

Ce que demande xtg c'est la formule employée pour créer la table:
Imaginons:
<?PHP
$requete = "CREATE table......";
print "<br>:$requete:<br>";
die();
?>
et tu envoies un copier/coller de l'affichage, que tu peux tester dans phpmyadmin....
au passage que vient fiche ce CHA:
`numeromobile` VARCHAR(15) UNSIGNED NULL, `adresseemail` VARCHAR(35) CHA'

Re: Problème SQL.

par xTG » 13 mars 2014, 21:00

Moi tout ce que j'ai demandé c'est la requête que tu tentes d'exécuter et qui échoues...
A savoir vu la tête une requête CREATE TABLE.

Re: Problème SQL.

par niconicochan » 13 mars 2014, 19:27

Je veux dire soit je t'envoie la table par email soit tu essayes de lire le tableau un peu destructuré
qui se trouve un peu plus haut en prenant en compte mon dernier message.

Re: Problème SQL.

par niconicochan » 13 mars 2014, 19:24

Le fichier WORD que j'ai crée n'est pas autorisé non plus. :evil:
Je ne sais plus quoi faire.
Soit je t'envoie ma table par adresse e-mail, si tu arrives à lire mon tableau
en sachant que dans les quatres premières colonnes que sont Nom, Type, Taille/Valeur
et Défaut tous les champs ont une valeur, qu'ensuite...
...pour interclassement il y a quatre champs vide: age, numerotelephone,
numeromobile et adresseemail, que dans attributs il y a seulement six champs remplis
(BINARY pourfirmeouinon et pour sexe, UNSIGNED pour numerotelephone, numeromobile,
numerorue et codepostal, qu'il y a que quatre champs cochés pour null: sexe, age,
numerotelephone et numero mobile - ces champs correspondent à des champs facultatifs
pour l'utilisateur dans le formulaire du site et qu'il y a la PRIMARY dans Index pour nomutilisateur
et motdepasse, et rien pour tous les autres champs.
Soit tu as une meilleure idée.

Re: Problème SQL.

par niconicochan » 13 mars 2014, 19:02

Bon, j'ai refait le fichier en mode Excel mais le site du forum
n'accepte pas les fichiers Excel non plus.

Je réessaye avec WORD cette fois...

Re: Problème SQL.

par niconicochan » 13 mars 2014, 18:32

C'est pas terrible, je vais refaire avec une feuille Excel.

Re: Problème SQL.

par niconicochan » 13 mars 2014, 18:31

NOM TYPE TAILLE/VALEUR DEFAUT Interclassement Attributs null Index

nomutilisateur SERIAL 10 Aucune UTF8_general_ci Primary
motdepasse SERIAL 8 Aucune UTF8_general_ci Primary
firmeouinon TEXT 3 Aucune UTF8_general_ci binary
nomfamille TEXT 25 Aucune UTF8_general_ci
prenom TEXT 25 Aucune UTF8_general_ci
sexe TEXT 5 Aucune UTF8_general_ci binary V (encoche)
age VARCHAR 3 Aucune V (encoche)
numerotelephone VARCHAR 15 Aucune unsigned V (encoche)
numeromobile VARCHAR 15 Aucune unsigned V (encoche)
adresseemail VARCHAR 35 Aucune UTF8_general_ci
numerorue CHAR 2 Aucune unsigned
nomrue TEXT 25 Aucune UTF8_general_ci
codepostal CHAR 15 Aucune UTF8_general_ci unsigned
ville TEXT 25 Aucune UTF8_general_ci
pays TEXT 25 Tel que défini: UTF8_general_ci
France

Moteur de stockage:
InnoDB (ce n'a pas été écrit par moi)

Interclassement:
UTF8_general_ci

Re: Problème SQL.

par niconicochan » 13 mars 2014, 18:10

Je l'ai scanné et en voulant l'envoyer, le fichier PDF n'a pas été autorisé à partir.
Changer d'extension (par exemple .txt) brouille le fichier.
Je peux soit l'envoyer par e-mail, soit réécrire la table dans un message.
A moins que tu as une autre idée par faire passer le fichier via un message du forum.