Bonjour, je viens d'apprendre que le chiffre spécifié dans les parenthèses d'un INT(X) dans MySql n'affecte pas la taille du champ mais simplement la taille d'affichage des résultats, d'où une question que je me pose et à laquelle je trouve aucune réponse, quel intéret ?
 
Merci  

Pas compris ?
int(1) = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
int(2) = 0, 1, 2, 3, 4, ..., 99
int(3) = 0, 1, 2, 3, 4, ..., 999
Etc...

  int(1) = int(2) = int(3) = int(X)  
dans tous les cas un champ INT sous MySQL gère jusqu'a 2^32 (4 octets)
 
en réalité il ne sert que pour le formattage des résultats :
exemple :
tu as dans la base :
1
10
100
1000
10000
100000
 
avec INT(3) et ZEROFILL activé (pour que ce soit visible)
tu auras apres un select :
001
010
100
1000
10000
100000
 
d'où ma question d'en connaitre l'intéret...

Tu viens de le dire j'imagine. C'est le fait d'avoir les champs rempli d'une certaine maniere.
Imagine une date : 01.02.2003 , on peut l'abbreger 01.02.03 , maintenant sans zerofill et int 2 :
1,2,3 ... Ca le fait pas trop comme date ..
 
Du moins c'est la conclusion a laquelle je suis arrivé

oui il doit certainement y avoir des applications concrètes, mais je ne vois vraiment pas quoi, et pour une date...

Ha oui me suis trompé effectivement ;p

tu parles du type numeric (ou number selon les SGBD) là...

Sinon, ça me semble un bug de MySQL ça.
 
Parceque la norme SQL prévoit que le nombre passé en paramètre à INT soit le nombre de bits utilisés pour représenter l'entier (là où le paramètre représente le nombre de chiffres avec le type numeric)

Arf, non, même pas, le type INT ne recois pas de paramètres, et est un 32 bits signé dans la norme SQL.
SQL Server accepte un paramètre, "4", correspondant à 4 octets, donc 32 bits. Ce paramètre est constant et ne peut être modifié.
 
Bref, les dévelopeurs de MySQL ont fumé sur ce coup là !

Ou alors, il ne font que permettre de passer un paramètre, qui est tout bonnement ignoré.
 

Euh... Une date, ça se stocke de toute façon jamais comme ça dans la base !
 
Soit tu as un type DATETIME, et tu l'utilises.
Soit tu n'en as pas, et tu utilises le format ISO : "YYYYMMDD HH:MI:SS" au format CHAR(8) ou CHAR(17) selon si tu veux l'heure ou non. En aucun cas sous forme d'un INT !
 
A la limite, tu peux stocker dans un format INT uniquement la valeur illisible résultat d'un CAST vers le type INT d'une variable DATETIME (il va contenir la représentation interne, au format DATETIME, de la date sans l'heure).
En effet, un DATETIME, c'est un bête float, dont la partie entière représente la date, et la partie décimale l'heure. Un cast vers INT permet donc de ne garder que la partie date, et économiser un peu de place.

Je sais ... je cherchais juste une explication .. et c'est la moins stupide qui me soit venue a l'esprit ...
 

Sinon, juste un truc à propos de mon dernier post à propos des dates.
 
Je viens de vérifier dans SQL Server, et il accepte les transtypages vers le type interne "float".
 
Ainsi :

A noter qu'avec MySQL, ça ne marche pas, puisque ce dernier ne travaille pas avec le type système "date", mais avec des timestamp (dates à la sauce Unix et non Microsoft / ISO).
Un timestamp est un double (32 bits) contenant le nombre de millisecondes depuis je ne sais plus quelle date (je crois pas que ce soit 01/01/1900 comme Microsoft)
Donc on obtiens la date en faisant une division par 1000 * 60 * 60 * 24
Et l'heure avec un modulo 1000 * 60 * 60 * 24

Non le timestamp unix commance dans les années 70 si je me rappelle bien...
 
Edit :  

 
Tirer de la fonction date de php qui est basée apperemment sur mysql

c'est bien ce qu'il me semblait

 
disons qu'ils ont plutot interprété à leur sauce, puisque la doc MySQL explique à quoi sert le chiffre passé en paramètre, que j'ai illustré d'un exemple plus haut...
 
Donc soit ils ont fumé, soit il y a une réelle utilisation possible de cette fonctionnalité, mais je cherche encore laquelle...

 
eh oui, plus que 33 ans avant le bug...  

Mouais ... Ca va encore etre un truc comme le 9 septembre 99 ou le millenium bug ... 1 grand coup de fumée dans les yeux

et un grand coup de cash dans nos poches pour tout plein de patchs  

Oue sauf qu'il faudrait que ca pete vraiment fort pour que ce soit rentable .
 
Et d'ailleur la pluspart des site n'utilise pas le timestamp tel quel (seul les geeks le font apperemment ), donc suffi que PHP relache un patch pour date() et hop, on a plus rien dans nos poches

que veux tu dire par "la pluspart des site n'utilise pas le timestamp tel quel " il y en a qui affichent "Bonjour, il est 21479272 secondes de plus que le 1er janvier 1970" ???  

Non, ca veut dire que si tu vas dans la base de donnée / fichier de cache, ils ont stoquer 1er janvier 1970 plutot que 0 ... Et 10 min apres le webmaster arrive ici en pleurant parcequ'il arrive pas a calculer une date ... et oui c'est dur la vie quand on utilise pas le timestamp

d'où l'intérêt de gérer les dates comme le préconise ISO, en format texte : "YYYYMMDD HH:MI:SS mmm"
 
Ca plantera le 31 décembre 9999 à 23h59 et 59,999 secondes, on a vraiment le temps de voir venir

Et l'intérêt, c'est qu'on peut traîter de le moyen-age aussi, sans nécessiter des astuces bidons de ouf

et avant JC tu fais comment ?  

 
Oue mais le timestamp c'est bien utile quand meme.. Rien a fouttre des mois de fevrier & co ...

Sinon, euh...
Y'a un souci avec la citation d'esox_ch...
 
Je suis sous NT 4.0 SP6 et :
 

 
=> SQL Server part donc de 1900 et non pas de 1970. Vu que c'est un produit Microsoft, j'en déduis qu'ils ont certainement utilisé le type système.
=> A noter que vu que c'est un float, il est signé, et du coup on peut modéliser des dates antérieures à 1900
 
 
Et avec VBS :

 
Idem donc, sauf qu'il commence à compter deux jour avant (étrange )

Ben au pire, tu peut toujours mettre un - devant. La notation avec sciècle le permet certainement d'ailleurs

Tout dépends de l'utilisation... Mais moi je préfère très franchement utiliser ce format.
Plus facile pour retrouver "le 1° jour du mois suivant".
Parceque avec MySQL et un timestamp, je te raconte pas la requête de timbré que ça fait, pour vraiment pas grand chose )

Ok donc avec ton castage, le systeme va se demerder pour les années bisextiles & co...
Pratique en effet