Reprise du message précédent :

 
Ouais mais s'il le fait maintenant il aura rien a faire les autres jours, et il se fera virer

Viré ça risque pas, je fais ça pour un pote qui monte sa boite
Et je m'inquiète pas pour m'occuper, j'ai mon mémoire de master d'anglais à rendre dans un mois (Et un boss sympa qui m'a embauché pour commencer fin mai alors qu'il voulait commencer le projet de suite)
 

 
 
section "type de colonnes"
 
http://dev.mysql.com/doc/refman/5. [...] ments.html  

spam
http://forum.hardware.fr/hardwaref [...] 8794-1.htm

SISMO

Exact
 

C'est pas plustôt pour avoir un format de date qui enléve toute embiguité? Quand on a 2006-05-02, on sait que c'est le 2 mai 2006, par contre, si on a 04032006 ou pire 040306, alors il est impossible de savoir si c'est le 4 mars 2006 (date francaise) le 3 avril 2006 (date américaine) ou dans le cas du 040306 le 6 mars 2004. (format de date ISO réduit)
Pour le tri dans Mysql, de toute maniére, vu que la date est stocké sous forme d'octet, on se fiche un peu du format d'affichage. Par contre, c'est sur que dans les programmes utilisant mysql, le fait de recevoir les date sous forme de chaine au format ISO permet de la trier par ordre alphabétique.  
 

Voilà ce qui est dit dans la doc officielle pour mysql 5 :
Type de colonne => Espace requis  
DATE => 3 octets  
DATETIME => 8 octets  
TIMESTAMP => 4 octets  
TIME => 3 octets  
YEAR => 1 octet  
Comme tu vois, avec mysql, un timestamp, c'est 4 octets donc 32 bits et un datetime, c'est 8 octets donc 64 bits.
A noter que le timestamp commence en 1970 et ne va pas au delà de 2037 alors que le datetime va de l'an 1000 à l'an 9999 soit un intervale de validité beaucoup plus important d'où une consomation mémoire plus importante.

ça c'est pour le stockager MySQL, mais pour le traitement et la récupération derrière, en PHP par exemple ?
Sinon, perso, pour le timestamp, je n'utilise aucun de tes champs, j'utilise un int(10) unsigned, c'est grave docteur ?

bah, tes champs prennent deux fois plus de place pour...rien

et puis mysql gère bien les dates, y'a rien à ajouter comme traitement php

 
Si tu formates la date avec SQL, alors faire un tri n'est pas possible    
 
C'est de quoi on parle depuis le début  

C'est ça quand on apprend sur le champ et quand on n'a pas de bases solides en dev  et quand on ne sait pas lire l'angais

Je vais te prier de fermer ta gueule de petit con, parce que si c'est juste pour brasser de l'air et faire chier la marine c'est pas la peine merci

T'es mignon, je devais développer que tu n'avais jamais goutté l'alcool.  
En l'occurence, un int(10) prend 5 octets dans une bdd myslq et un timestamp prend... tintintintin... 5 octets dans une bdd mysql.
 
Donc, t'es mignon quoi.

Bah, si tu enregistres 3 dates en mémoire sous forme de chiffre, ça prend quedal en mémoire, mais si tu l'enregistres sous forme de texte, ça prend beaucoup plus de mémoire.

au boulot

Et accessoirement tu te plantes super super super violent, là, genre tu devrais un peu être mort de honte et aller te cacher, comme gatsu
 
int(10) ne prend pas 5 octets dans la DB il en prend... tintintin... 4
 
Et pour les couillons genre gatsu, int(10) ne veut pas dire 10 entiers d'1 caractère, ça veut dire que si ZEROFILL est activé sur la colonne alors celle ci sera paddée jusqu'à une largeur de 10 à la récupération:
 
Si tu veux stocker 263 dans ta DB, que ton champ soit un INT, un INT(1), un INT(4) ou un INT(10) ça sera toujours stocké 263 sur 4 octets (32 bits), par contre si ZEROFILL a été activé quand la colonne a été créée alors à la récupération de notre valeur on recevra respectivement 263, 263, 0263 et 0000000263.

Bah avant d'affirmer quelquechose, j'ai testé, en l'occurence, je viens de créer un table contenu une unique colonne de type INT 10 Unsigned
J'ai enregistré 2 valeurs et j'ai  
Données   10   Octets
dans PHPMyAdmin
 
Et 2 octets pour 2 insertion, ça fait 10 divisés par 2, ça fait 5 octets par INT(10).    

J'veux pas le savoir, la doc elle dit 4 octets

Tu as raison, autant pour moi.
en fait, il doit y avoir un octets pour je ne sais quoi parce que quand je rajoute un colonne de int(10), j'obtients 2 insertion = 18 octets.
 
Et pareil avec un Timestamp, donc, DTC Gatsu quand même.  

M'enfin pourquoi stocker un timestamp en int(10) alors que il y a des types fait pour ça
 
Nécessité, besoin ?? Où c'était déjà comme ça ?

ou parce qu'il connait pas tout simplement.

Tout simplement parce que PHP et sa fonction time() te retourne un int(10) qui ne sera pas compatible avec un timestamp sans conversion dans une bdd. Alors qu'en faisant :

fonctionnera si la colonne time est un int(10) mais pas si c'est un timestamp.  

 
 
sauf que ça fontionne très bien un order avec les champs date
 
quelqu'un peut donner un exemple

 
 
formatage SQL merde
 
en passant par un autre type tu perds toutes les fonctions associées super pratiques

Cites moi une fonction PHP qui ne fonctionne pas avec mes INT(10) ?
 
Je suis peut-être un news en programmation PHP/MySQL, enfin, depuis presque 20 ans que je développe, il y a une info qui n'a jamais été contredite, c'est qu'en programmation, la valeur la plus rapide à traiter, c'est un chiffre.    

 
 
je parle des fonctions mysql  
 
 
pas besoin de se palucher des calculs d'entiers pour sortir un interval de date ou autre, tu fais n'importe quel SELECT / INSERT / UPDATE en quelques secondes
 
toi tu dois te palucher des manips via l'appli alors que la BDD peut le gérer à l'aise, je trouve ça moins pratique

Moi je ne trouve pas ça moins pratique, PHP a été fait pour travailler sur mon INT(10).
Après, chacun ses choix, mais qu'on arrête de venir me dire que je fais n'importe quoi.    

 
c'est surtout pas logique, et le gain est nul, de là je vois vraiment aucun intérêt à pas utiliser les outils natifs qu'on a à disposition
 
comment tu fais si t'as besoin de sortir toutes les lignes écrites un vendredi ? à 10H précises ?

Bah oui ça marche très bien...quel est le pb?

 
développe un peu je te prie, c'est pas moi qui dis qu'un tri avec une date formatée par SQL fonctionne pas..

 
entre les noms d'oiseaux et les pseudos débats de méthodologie j'avoue qu'on s'y perd un peu, alors soit il manque des smileys sur certains post soit on raconte n'importe quoi mais c'est lourd et dur à suivre

 
  Hum avant de dire des conneries j'ai des choses a tester  

Je le fais en PHP et ça tombe bien, parce que PHP travaille beaucoup mieux sur des récupérations de timestamp INT(10).    

 
 
mieux ? en quoi ?
 
et je veux bien l'exemple pour récupérer des lignes avec une date correspondant au jour de vendredi

Bah time te retourne un integer, strtotime, la fonction date travaille avec un integer, etc.
 

Quoi ? Tu sais pas faire ça tout seul ? la honte...

 
 
je sais le faire en SQL, mais je veux bien le voir en php

if (date('w',time())==5) { echo 'youpi, c\'est vendredi';}

 
 

 
dans une table, on parle bien d'utiliser un entier plutôt que le champ ad hoc dans MySQL
 
imagine une table avec quelques centaines de milliers de lignes, et j'aimerais savoir combien j'ai de ligne pour chaque vendredi, chaque mois de décembre, etc etc
 
donc moi je suis partisan de le faire avec un champ DATE / DATETIME et un peu de SQL, toi tu utilise un entier et php, j'aimerais connaitre la solution

Bah je t'ai donné la solution en PHP.    
Après, on s'en fout de connaitre tous les vendredis mais bon, c'est sûr, aucune méthode n'est parfaite, ni la tienne ni la mienne, sinon, on en parlerait pas, ça se saurait.    
 
C'est un peu comme Joce qui n'utilise jamais Enum dans MySQL, qui préfère utiliser un tiny int, ha bah oui, mais c'est Joce, lui il a choisi ça, ça ne se discute pas...    
 
Bon et à part trouver tous les vendredis, le truc qui ne servira jamais, t'as un autre inconvénient concret à me montrer ?

bin ça va être valable pour tous les groupements, tu peux faire quasiment aucune stat, avec ton INT t'es coincé
 
entre l'enum et le tinyint par contre tu perds absolument rien parce qu'il n'y a aucune fonction associée, tu saisis la différence ?
 
et ce n'est pas ma méthode, c'est celle qui tombe sous le sens