MySQL a répondu : Duplicata du champ '127' pour la clef 1

par **Augure** » 14 juil. 2005, 13:27

Dans l'absolu tu as raison .... dans la pratique aprés pas mal d'année de projet ... tu apprends à te simplifier la vie

Je préfére miniser le nombre de type en les maximisant un peu que j'utilise. Cela evite les erreurs de mismatch de conversion et evite souvent la nécéssité de changer un type car la table grandit plus que prévu.

L'utilisation de INT à la place de TINYINT à peu d'impact. En effet dans cette table il ne pouvait y avoir que 256 valeurs. Il est impossible de voir une différence de performance (*)

Par contre une table ou tu as des millions d'enregistrement passer de INT à BIGINT la différence peut être quantifiable et qualifiable.

Conclusion sachons se simplifier la vie sans tomber dans l'excés

(*) : Ok on peut dire la que je ment un peu .... indirectement

par **pjl** » 14 juil. 2005, 10:42

Je ne suis pas d'accord.

La taille du champ est à déterminer en fonction des besoins.

Si tu veux la liste des départements français par ex, un tinyint suffit largement.

Sinon, en suivant ton raisonnnement, pourquoi ne pas utiliser un BIGINT pour les chiffres et un LONGTEXT pour les suites de caractères ?

par **Augure** » 13 juil. 2005, 23:01

taille en octet .... c'est le nombre d'octet nécéssaire pour stocker sur ton disque une valeur du type considéré.

C'était des infos importante quand le prix du Mo était chére ou quand on faisait du C/C++.

Retiens juste que INT c'est le plus courant, donc facilite toi la vie

par **Invité** » 13 juil. 2005, 22:57

Code : Tout sélectionner
Type Taille Octets De A TINYINT 1 -128 127 SMALLINT 2 -32768 32767 MEDIUMINT 3 -8388608 8388607 INT 4 -2147483648 2147483647
Si pascaltje à vu juste, je te conseille de prendre le Type INT qui est le plus standard de nos jours.

Sympa ton explication et encore merci a vous deux...

Que represente la colonne taille octet dans ton tableau ( le poids de l'information)?

par **Roups** » 13 juil. 2005, 22:54

Mon champs clef etait en tinyint(4) que j'ai mis en int(11).

Ca refonctionne, merci...

Je fais tout de meme deux ou trois verif avant de valider mon message....

C'est ok

Merci

par **Augure** » 13 juil. 2005, 22:51

Code : Tout sélectionner

Type       Taille Octets    De         A  
TINYINT         1           -128        127  
SMALLINT        2         -32768      32767  
MEDIUMINT       3       -8388608    8388607  
INT             4    -2147483648 2147483647

Si pascaltje à vu juste, je te conseille de prendre le Type INT qui est le plus standard de nos jours.

par **pascaltje** » 13 juil. 2005, 22:46

ton champ est un entier qui prend comme valeur maximale 127.

il faut le modifier en un entier qui accepte des valeurs plus grandes - via phpmyadmin par exemple, et tu seras tranquille un bout de temps.

A+

Pascal

par **Roups** » 13 juil. 2005, 22:35

Bonjour,
Quelqu'un a t il une explication ?
Je vous explique.

Chaque tables a une clef primaire qui s'autoincremente.

J'ai une table saisie, ou j'enregistre des fiches et un numero Id_saisie qui me sert dans la table actions comme lien.

Tout fonctionne bien :

J'enregistre mes fiches, je les selectionne, et j'y ajoute des actions (dans la table action).

Seulement arriver a la 127ieme actions mysql repondu :

Code : Tout sélectionner

requête SQL :  

INSERT INTO actions (id_lien_saisie, action, date_action) VALUES ('$Id_saisie','$Action','$Date')

MySQL a répondu:


Duplicata du champ '127' pour la clef 1

Je suis tout ouie, merci de votre aide.

MySQL a répondu : Duplicata du champ '127' pour la clef 1

Répondre

Étendre la vue Revue du sujet : MySQL a répondu : Duplicata du champ '127' pour la clef 1

effectivement [RESOLU]

MySQL a répondu : Duplicata du champ '127' pour la clef 1