Bonjour à tous,
 
Ça fait un bout de temps que j'utilise MySQL, et j'ai toujours autant de "mal" à choisir correctement le bon type de colonne.
 
Savez-vous s'il existe un site qui regrouperait les types recommandés pour chaque type de contenu ?
 
Car bien evidemment, c'est vague et c'est au choix de chacun, mais je pense que ce serait sympa une base de départ.
 
Par exemple, je suis en train de me poser la question pour stocker des tarifs (qui ne dépasseraient jamais 999€99), le type le plus approprié est-il un FLOAT(5,2) ?
 
Merci par avance
 
P.S. : Un autre exemple serait un code postal ... faut-il utiliser un CHAR(5), un VARCHAR(5) ou plutôt des types numérique ? (je voterais plutôt pour CHAR(5), j'ai bon ? )

Pour les codes postaux pas du numérique parce que sinon tu vas perdre le 0 pour les départements <10
 
Moi aussi je prendrais du CHAR(5) car TOUS les codes postaux ont 5 caractères...
 
Le VARCHAR je l'utilise plus quand la taille du champ est variable genre un libellé.
 
Sinon j'ai pas de lien à te filer, désolé

Merci quand même pour ta participation
 

un lien que je trouve sympa : http://www.destrucsaweb.com/ressou [...] oto_71.php

 
Dommage que ce lien ne fonctionne plus.

pour un CP : char(5) si tu as des CP uniquement français , histoire de conserver le 0 devant  
 
pour des tarifs float > en effet, ca prends moins de pace et et u peux faire des requetes arithmétiques ( prix < 100e par exemple) ou des sommes

En fonction des besoins, on peut aussi envisager un type "INT" (il suffit de considérer que la valeur est exprimée en centimes )

 
Faux.
Certains CP font plus de 5 caractères. C'est d'autant vrai si demain le site se trouve à être multi-nationnal.
 
Re-faux.
Un varchar(5) fait AU PLUS 5 caractères. Tout comme le CHAR, toute tentative de dépassement résultera dans une troncature du champ.
 
CHAR n'est recommandé que dans le cas où tu as besoin de grandes performances sur une table, ou que tu es absolument sûr et certain de la taille du champ (par exemple, une clé de cryptage).
Dans le cas contraire, le problème c'est que "A" en CHAR(5) est représenté "A____" ce qui mesure donc 5 caractères. Tout traîtement sur les chaînes par la suite impliquera donc l'utilisation intensive,abusive et inutile de Trim() sur la chaîne afin d'enlever les espaces superflus.
 
 
Pour ce qui est de FLOAT(5,2) c'est une hérésie. Les chiffres passés en paramètre n'ont à priori aucun impact, autre que l'affichage dans certains éditeurs SQL.
Un FLOAT, c'est un FLOAT, point barre.
 
Pour des tarifs, travailler en float est une erreur, car les calculs en virgule flottante ne sont pas précis, et il peut en résulter des écarts. De même, les calculs en virgule flottante ne sont pas fixes en nombre de décimales, ce qui peut impliquer des arrondis erronnés : (10,01 € / 10) * 10 = 10 € dans la vraie vie, pas 10,01 comme te donneras un float.
 
Tu dois donc travailler avec le type NUMERIC/DECIMAL, qui proposent une représentation à virgule fixe : NUMERIC(5,2) = 000,00 et la précision est absolue et figée : parfait pour travailler avec des prix.

PS : c quoi ce vieux topic qui sent le moisi ? Et moi qui poste dedans comme un con

Je voulais juste un nouveaut site.

Merci de l'info, j'ai appris quelque choses.

+1 c'est du bon déterrage de topic çà

Justement...

 
 
Un Float est un Float et les paramètres qu'on y passe ne serve qu'a l'affichage?
Tu as été trouvé cela ou? c'est du gros n'importe quoi.  
 
Essaye de mettre 7.123456789 dans un float(7.2), ton nombre sera tronqué ou arrondi en fonction des SGBD.  
Fais l'expérience et tu veras ce que ça donnera. Du moins avec ORACLE et SQL SERVER c'est comme cela, et la norme SQL2 l'exprime également de cette façon...

euh... je vérifie un truc, mais à la base...
 
pour moi, y'a pas de "float" dans la norme SQL92
 
son "équivalent" c'est "double"
 
et il ne prends pas de paramètres à la déclaration
 
je check

alors donc :
 
1/ C'est bien "float" le nom en SQL 92 (confusionné avec le "double precision" )
2/ Il ne supporte qu'un seul paramètre, qui n'as rien à voir avec le nombre de décimales, mais le nombre de bits utilisés pour stocker le nombre. En somme, que le paramètre doit grand ou petit, le RANGE des valeurs est le même, par contre la précision va varier.
 
Donc 7.123456789 dans un float(7) et non float(7.2) donnera peut-être 7.123456788 à la place de la valeur exacte, mais en aucun cas fera d'arrondi.
 

 
Test :

declare @test1 AS float(4)
declare @test2 AS float(53)
 
SET @test1 = 0.12345678901234567890
SET @test2 = 0.12345678901234567890
 
SELECT @test1
SELECT @test2

 
tout ça pour dire que si dfans mysql il y a un second paramètre, soit il ne sert qu'à l'affichage, soit float est alors un synonyme de decimal et non de float, soit mysql (comme d'habitude) est une grosse bouse infâme qui n'a rien de compatible avec sql92

RTFM : http://dev.mysql.com/doc/refman/5. [...] types.html

 
En gros, si j'ai bien pigé, avec mysql, soit on définit la colonne comme indiqué dans la norme SQL92 (auquel cas, c'est conforme à la nombre SQL92) soit on définit la colonne en indiquant deux nombres auquel cas c'est comme un synonyme de DECIMAL mais stocké dans un float (ne me demande surtout pas pourquoi ils stockent les DECIMAL comme des chaines de caractères)

et donc, comme je disais au début, si on spécifie une précision au type float, c'est qu'on n'a pas besoin d'un float, mais d'un decimal
 
 

De toute façon quand on fait de la finance il faut toujours utiliser soit des entiers (e.g. en centimes) ou des décimaux, jamais des floats

declare @test1 AS float(4)
declare @test2 AS float(53)
 
SET @test1 = 0.12345678901234567890
SET @test2 = 0.12345678901234567890
 
SELECT @test1
SELECT @test2

 
je dois me tromper avec les NUMBER d'oracle alors. Car les number oracle, numeric en SQL SERVER, se comporte comme je te l'ai expliqué.  
 
NUMBER(4,2) => 2 décimales
NUMERIC(4,2) => 2 décimales

Oui, c'est NUMBER, qui est effectivement un synonyme de NUMERIC, qui est un synonyme de DECIMAL
 
FLOAT, c'est un type complètement à part, dont le comportement est totalement différent
Le paramètre est similaire à celui de INTEGER, à la différence près qu'en FLOAT, la taille en mémoire n'influence pas le range de valeurs, mais uniquement la précision

http://dev.mysql.com/doc/refman/5. [...] types.html