Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1914 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  question existentielle MySQL : INT(x)

 
 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

question existentielle MySQL : INT(x)

n°1185346
misterping​uin
Posté le 26-08-2005 à 15:05:15  profilanswer
 

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  :pt1cable:

mood
Publicité
Posté le 26-08-2005 à 15:05:15  profilanswer
 

n°1185385
Masenko
Posté le 26-08-2005 à 15:17:49  profilanswer
 

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...

n°1185438
misterping​uin
Posté le 26-08-2005 à 15:36:45  profilanswer
 

Masenko a écrit :

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...


 :non: 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...

n°1185465
esox_ch
Posté le 26-08-2005 à 15:47:51  profilanswer
 

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é


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
n°1185474
misterping​uin
Posté le 26-08-2005 à 15:50:54  profilanswer
 

esox_ch a écrit :

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...

n°1185534
Masenko
Posté le 26-08-2005 à 16:15:06  profilanswer
 

Ha oui me suis trompé effectivement ;p

n°1188187
Arjuna
Aircraft Ident.: F-MBSD
Posté le 30-08-2005 à 19:58:40  profilanswer
 

Masenko a écrit :

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...


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

n°1188188
Arjuna
Aircraft Ident.: F-MBSD
Posté le 30-08-2005 à 20:00:33  profilanswer
 

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)

n°1188195
Arjuna
Aircraft Ident.: F-MBSD
Posté le 30-08-2005 à 20:05:23  profilanswer
 

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à !

n°1188196
Arjuna
Aircraft Ident.: F-MBSD
Posté le 30-08-2005 à 20:05:56  profilanswer
 

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

esox_ch a écrit :

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é


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.


Message édité par Arjuna le 30-08-2005 à 20:09:54
mood
Publicité
Posté le 30-08-2005 à 20:05:56  profilanswer
 

n°1188207
esox_ch
Posté le 30-08-2005 à 20:27:29  profilanswer
 

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


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
n°1189363
Arjuna
Aircraft Ident.: F-MBSD
Posté le 01-09-2005 à 12:01:48  profilanswer
 

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 :

Code :
  1. -- Récupération du jour sans l'heure
  2. select cast(floor(cast(getdate() as float)) as datetime)
  4. -- Récuparation de l'heure sans jour (01/01/1900)
  5. select cast((cast(getdate() as float) - floor(cast(getdate() as float))) as datetime)


 

Code :
  1. ------------------------------------------------------
  2. 2005-09-01 00:00:00.000
  4. (1 ligne(s) affectée(s))
  6.                                                      
  7. ------------------------------------------------------
  8. 1900-01-01 11:49:58.177
  10. (1 ligne(s) affectée(s))


Message édité par Arjuna le 01-09-2005 à 12:06:47
n°1189366
Arjuna
Aircraft Ident.: F-MBSD
Posté le 01-09-2005 à 12:03:08  profilanswer
 

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


Message édité par Arjuna le 01-09-2005 à 12:03:54
n°1189387
esox_ch
Posté le 01-09-2005 à 12:16:42  profilanswer
 

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

Citation :

L'intervalle de validité d'un timestamp va généralement du Vendredi 13 Décembre 1901 20:45:54 GMT au Mardi 19 Janvier 2038 03:14:07 GMT. (Ces dates correspondent aux valeurs minimales et maximales des entiers 32 bits non-signés). Sur les systèmes Windows, cette intervalle va du 01-01-1970 au 19-01-2038.


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


Message édité par esox_ch le 01-09-2005 à 12:19:23

---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
n°1189392
Arjuna
Aircraft Ident.: F-MBSD
Posté le 01-09-2005 à 12:18:19  profilanswer
 

c'est bien ce qu'il me semblait ;)

n°1189432
misterping​uin
Posté le 01-09-2005 à 12:59:29  profilanswer
 

Arjuna a écrit :

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)


Citation :

Bref, les dévelopeurs de MySQL ont fumé sur ce coup là !


 
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...


Message édité par misterpinguin le 01-09-2005 à 13:00:02
n°1189438
misterping​uin
Posté le 01-09-2005 à 13:02:00  profilanswer
 

esox_ch a écrit :

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

Citation :

L'intervalle de validité d'un timestamp va généralement du Vendredi 13 Décembre 1901 20:45:54 GMT au Mardi 19 Janvier 2038 03:14:07 GMT. (Ces dates correspondent aux valeurs minimales et maximales des entiers 32 bits non-signés). Sur les systèmes Windows, cette intervalle va du 01-01-1970 au 19-01-2038.


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


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

n°1189444
esox_ch
Posté le 01-09-2005 à 13:07:44  profilanswer
 

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


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
n°1189446
misterping​uin
Posté le 01-09-2005 à 13:09:08  profilanswer
 

esox_ch a écrit :

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


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

n°1189449
esox_ch
Posté le 01-09-2005 à 13:11:19  profilanswer
 

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


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
n°1189491
misterping​uin
Posté le 01-09-2005 à 14:11:59  profilanswer
 

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" ???  :whistle:

n°1189513
esox_ch
Posté le 01-09-2005 à 14:34:18  profilanswer
 

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


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
n°1189514
Arjuna
Aircraft Ident.: F-MBSD
Posté le 01-09-2005 à 14:34:43  profilanswer
 

esox_ch a écrit :

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


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 :D

n°1189516
Arjuna
Aircraft Ident.: F-MBSD
Posté le 01-09-2005 à 14:35:57  profilanswer
 

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 :)

n°1189519
misterping​uin
Posté le 01-09-2005 à 14:40:51  profilanswer
 

Arjuna a écrit :

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 ?  [:misterpinguin]


Message édité par misterpinguin le 01-09-2005 à 14:41:04
n°1189522
esox_ch
Posté le 01-09-2005 à 14:44:51  profilanswer
 

Arjuna a écrit :

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 :D


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


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
n°1189526
Arjuna
Aircraft Ident.: F-MBSD
Posté le 01-09-2005 à 14:49:21  profilanswer
 

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

Code :
  1. select cast(null as datetime)
  2. select cast(0 as datetime)
  3. select cast(1 as datetime)
  4. select cast(2 as datetime)
  5. select cast(-1 as datetime)
  6. select cast(-10000 as datetime)


 

Code :
  1. ------------------------------------------------------
  2. NULL
  4. (1 ligne(s) affectée(s))
  6.                                                      
  7. ------------------------------------------------------
  8. 1900-01-01 00:00:00.000
  10. (1 ligne(s) affectée(s))
  12.                                                      
  13. ------------------------------------------------------
  14. 1900-01-02 00:00:00.000
  16. (1 ligne(s) affectée(s))
  18.                                                      
  19. ------------------------------------------------------
  20. 1900-01-03 00:00:00.000
  22. (1 ligne(s) affectée(s))
  24.                                                      
  25. ------------------------------------------------------
  26. 1899-12-31 00:00:00.000
  28. (1 ligne(s) affectée(s))
  30.                                                      
  31. ------------------------------------------------------
  32. 1872-08-15 00:00:00.000
  34. (1 ligne(s) affectée(s))


 
=> 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 :

Code :
  1. msgbox CDate(0)
  2. msgbox CDate(1)
  3. msgbox CDate(2)
  4. msgbox CDate(-1)
  5. msgbox CDate(-10)


 

Code :
  1. 00:00:00 (c'est aussi 30/12/1899)
  2. 31/12/1899
  3. 01/01/1900
  4. 29/12/1899
  5. 20/12/1899


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


Message édité par Arjuna le 01-09-2005 à 14:52:55
n°1189528
Arjuna
Aircraft Ident.: F-MBSD
Posté le 01-09-2005 à 14:50:09  profilanswer
 

misterpinguin a écrit :

et avant JC tu fais comment ?  [:misterpinguin]


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

n°1189530
Arjuna
Aircraft Ident.: F-MBSD
Posté le 01-09-2005 à 14:51:34  profilanswer
 

esox_ch a écrit :

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


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 ;))

n°1189532
esox_ch
Posté le 01-09-2005 à 14:53:15  profilanswer
 

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


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  question existentielle MySQL : INT(x)

 

Sujets relatifs
Question a propos de Visual C++ 2005Formulaire HTML, PHP et Mysql... aïe ça coince !!!
Afficher le résultat d'une requête PHP et MySQLPb connection à MySQL en PHP
[MySQL & Images] Création d'images avec base de donnéeQuestion sur OCAML
[question a 2 euros] Où placer un fichier type login.php ?Problème de perf php/mysql
Insertion date dans MySQLquestion simpa :-p url..
Plus de sujets relatifs à : question existentielle MySQL : INT(x)

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.093 secondes

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)