Reprise du message précédent :

Je pars dans rien du tout, j'ai dis que je laissais chacun faire comme il veut, c'est le fromage qui m'a dit "T'es con avec ta méthode on peut pas trier les vendredi", j'ai prouvé le contraire, avec un peu d'humulité il s'écrasait et basta. Mais ça a dut le toucher dans son ego.
 
Et visiblement, Masklinn aussi procède comme moi.  

Quand tu rapatries les infos de la base de données, tu rapattri, par exemple, 100 dates "2006/21/03 12:23", tu rapatrie 16x100 = 1600 kilos octets, quand tu les rappatris en timestamp Unix, ça fait le quart.  

MAI CAI SUPAIR§§

+1 pour la 1ere pour moi
 

Et non c'est pas le chanteur pour les deux boulets du fond!

ton optimisation est naze, tu gagne que dalle de que dalle puisque tu va convertir à chaque requête (en plus d'ajouter du php là dedans)
 
et un champ DATETIME c'est 8 octets, pas 10 ou 16, si on tombe sur une date seule, ton système prend un octet de plus
 
donc je suis peut être tétu, mais je trouve que ta solution est merdique

(ça vous dirait pas de poursuivre ce passionnant débat entre gens ouverts et diplomates en MP? )

 
t'as qu'à trouver un autre sujet de conversation
 
et puis c'est la faute à xtof s'il avait pas écrit qu'on peut pas trier un date_format() je serais pas venu

Faut-il setter les attributs d'un noeud avant ou après avoir fait un appendChild quand on utilise le DOM???
 
 

A partir du moment ou tu as créé ton noeud, tu peux setter les attributs comme tu veux et ensuite faire ton appendChild.
En règle général, je set d'abord et j'appendChild ensuite, comme ça, quand ton élément apparaît dans la page il est tout beau

Question con, mais en quoi le timestamp de mysql est différent de celui de php?
Il me semble que dans les deux cas, ca compte le nombre de secondes depuis le premier janvier 1970.

un bloc de taille fixe qui n'apparait pas a la bonne taille la premiere fois qu'on charge la page sous IE, ça vous dit quelque chose ?
et pas quelques pixels en plus ou en moins, mais à moitié plus petit

J'ai déjà eu ce genre de souci (bloc pas à la bonne taille au premier chargement)... pas trouvé de solution.

l'élément à la mauvaise taille est flottant ?
 
on dirait le peekaboo bug

 
c'est vendredi fallait que quelqu'un la fasse donc : changez de navigateur

cosmoschtroumpf > Il me semble que certains avaient eu ce genre de probléme à cause d'une taille spécifié dans le css sans avoir préciser l'unité de mesure.
Reste à savoir si c'est ça.

 
 
il me semble que ça vient de la gestion des fuseaux horaires

Et bien non
En fait IE supporte mal que tu settes certains attributs avant de faire l'appendChild et se vautre lamentablement ( IE7  included), la preuve?

 
onclick c'est le mal    

Pas vraiment non, au contraire même, j'ai beau avoir tendance à réinventer l'eau chaude j'ai autre chose à foutre que réinventer l'eau froide
 
De toute façon, pour résumer, tu nous a dit que PHP "fonctionnait comme toi", donc que grâce à tes timestamps PHP tu faisais tous tes traitements sur des dates en PHP, et au final tu utilises bel et bien les traitements de dates de MySQL. Pire, tu te retrouves obligé d'appeler des fonctions de reformattage (FROM_UNIXTIME) pour faire ces manipulations, donc au final il est plus probable que tu perdes des perfs à chaque fois que tu veux faire une manip' de dates "un peu trop avancées" (genre un tri ou un filtre sur des dates)
 
Accessoirement, si tu veux insérer l'heure actuelle dans un TIMESTAMP MySQL (faire l'équivalent à ton INSERT INTO matable (time) VALUES ("'.time().'" ) il suffit de faire INSERT INTO matable (time) VALUES (NULL), pas de cast, pas d'appel PHP, juste du qui marche simple et efficace)

C'est pas PHP qui fonctionne comme moi, tout langage basé sur PERL et Unix fonctionne comme moi. Tout simplement parce qu'il est ainsi beaucoup plus léger et rapide de récupérer des dates, choses beaucoup plus courante que de faire des tris complexes.
 
Pour l'anecdote, phpBB, Coolforum ou PunBB fonctionne comme moi, étrange pour une méthode à la con que je suis le seul à utiliser.

phpBB n'est pas vraiment une référence des chôses à faire ni une référence des méthodes de gain de rapidité ni une référence des méthodes de sécurisation du code.
 
phpBB est donc un script/forum à ne jamais citer pour dire que ce qu'on fait est génial par ce qu'ils font pareil.

J'ai pas dit que ma méthode était géniale, j'ai juste dit qu'elle était autant valable qu'une autre.
 
Et pour compléter, Phorum aussi utilise int(10) pour les dates.
Hé bé, ça en fait du monde qui utilise une façon de faire que personne ne connaissait avant hier à part moi.  

Mais tu me les brises, c'est pas moi qui l'ai dit, c'est toi bon sang de bois
 
Je n'ai fais que répéter ce que tu as posté une demi-douzaine de fois

C'est bon, j'ai oublié le "que", ce n'est pas que le PHP qui fonctionne comme moi. ça va, prend tes prozacs hein !  

Ce qui ne change strictement rien au fait que ton modèle de données est incohérent dans ta DB, et que tu es obligé de taper des conversions pour que la DB puisse utiliser les données y étant stockées, ce qui est sinon hérétique tout du moins stupide, pour des raisons d'intégrité référentielles les conversions se font aux interfaces, et pas en plein milieu du processus.
 
Et celà ne change rien non plus au fait que, contrairement à tes allégations initiales, tu n'effectues bel et bien pas tout ton traitement en PHP.
 
Sur ce, le sujet est clos pour autant que je sois concerné.

pourquoi ils utilisent un entier et pas un timestamp ?
 
un timestamp c'est génial, y'a pas de problème de compatibilité ni rien, c'est un entier
 
c'est 10 fois plus simple de faire une abstraction pour formater la date via php en utilisant un timestamp (moi je formate direct dans le sql, c'est pas plus lent..)
 
problème > à chaque update le timestamp va se mettre à jour, c'est pas cool ça sur un forum (tu n'as pas parlé de ce problème, mais je sens venir que c'est à cause de ça que tu utilise aussi un entier )
 
solution > bon bin y'a plus qu'à le mettre dans un champ INT pour contourner le problème
 
si le timestamp mysql avait pas cette propriété, ils utiliseraient un champ ad hoc sur ces scripts

Le premier timestamp de l'enregistrement  
 
Et ce comportement (à la con, franchement, même si la logique du raisonnement peut être comprite ) peut être désactivé, c'est même marqué dans la doc sur les timestamp comment on le fait

Bon on arrête les gros caca !!!!!!!!!!!!!!!
 
Je voudrais pas avoir à bannir quelqu'un ou pire .. à vous parler de flash

 
Encore une fois, tu ne travaille pas tant sur des int que tu le crois :
- dans l'appel à la fonction DATE_FORMAT, tu doit scanner un string "%W" :
- la valeur renvoyée par  DATE_FORMAT, tu la compare à un string, or voila le code de la fonction DATE_FORMAT quand on demande sa valeur en string (nécessaire pour faire la comparaison):

String *Item_func_date_format::val_str(String *str)
{
  String *format;
  TIME l_time;
  uint size;
  DBUG_ASSERT(fixed == 1);
 
  if (!is_time_format)
  {
    if (get_arg0_date(&l_time, TIME_FUZZY_DATE))
      return 0;
  }
  else
  {
    String *res;
    if (!(res=args[0]->val_str(str)) ||
    (str_to_time_with_warn(res->ptr(), res->length(), &l_time)))
      goto null_date;
 
    l_time.year=l_time.month=l_time.day=0;
    null_value=0;
  }
 
  if (!(format = args[1]->val_str(str)) || !format->length()) /* La c'est le parsing de ton "%W", léger le parsing hein? */
    goto null_date;
 
  if (fixed_length)
    size=max_length;
  else
    size=format_length(format);
  if (format == str)
    str= &value;                // Save result here
  if (str->alloc(size))
    goto null_date;
 
  DATE_TIME_FORMAT date_time_format;
  date_time_format.format.str=    (char*) format->ptr();
  date_time_format.format.length= format->length(); 
 
  /* Create the result string */ /* <-- c'est comme le port salut ... */
  if (!make_date_time(&date_time_format, &l_time,
                      is_time_format ? MYSQL_TIMESTAMP_TIME :
                                       MYSQL_TIMESTAMP_DATE,
                      str))
    return str;
 
null_date:
  null_value=1;
  return 0;
}

 
Wew, hé bé putain, ton int il a belle gueule ...  

Euh... et ça change quoi que ce soit un INT ou un Timestamp ? La comparaison se fera toujours sur un string non ?
 
J'ai fais quelques petits essais pour étayer ma théorie sur un forum de 45000 messages.
J'ai dupliquer la table des messages, j'ai remplacé la colonne time int(10) par un timestamp.
 
Je fais 2 récupérations, la première comme ça :

 
Et la deuxième comme ça :

 
La première méthode est naturellement affiché à l'aide la conversion adéquate en PHP :

 
Et la deuxième est affiché directement en récupération de la bdd, ce qui serait censé aller beaucoup plus vite.
 

 
Les temps de réponses sont pratiquement identiques, pratiquement à cause de l'instabilité du serveur pour calculer en microseconde, de toutes façons, ça donne tantot l'avantage à la première solution, tantot à la seconde.  
 
En revanche, la première requête retourne un tableau de 100000 octets et la deuxième un tableau de 190000 octets. Donc sur un script avec beaucoup d'utilisation simultanée, on consomme presque 2 fois moins de RAM.

 
pas avec la fonction DAYOFWEEK qui renverra un entier entre 0 et 7 et qui utilise uniquement un calcul arithmétique (cf code source si le coeur t'en dit), si ton choix de l'INT était vraiment argumenté en fonction du traitement rapide tu aurais employé DAYOFWEEK et pas DATE_FORMAT

Bah ça change rien.

 
Je n'ai pas dit que le int était plus rapide à traiter par MySQL, il est juste plus léger à récupérer et plus rapide à traiter en PHP ou tous autre langage qui utilise le timestamp Unix. Y'a quelqu'un qui parle le même langage que moi ici ?  

ça ne m'aide pas beaucoup....

 
nan, il est en position absolue et height:100%...... c'est ptet ça en fait
 
bon ben on dirait que c'est ça.... c'est con

j'ai une question con, y a moyen de connaitre le poids total de son site en PHP ?
 
pour un client (qui à 100Mo Pro chez amen) j'ai developpé un espace d'upload/download dans la partie privée du site, et je voudrais qu'il soit alerté quand on approche des 100 mega...
 
hors disk_free_space() me renvoie 19 Go (mutualisé powa), faut que je fasse un script de calcul du poids du site recursif et tout et tout a chaque upload/suppression de fichier, ou y a plus simple...

system('du -sk')?

disk_total_space Retourne la taille d'un dossier    
 
fr.php.net/disk_total_space

merci pour ta reponse je vais essayer ca, mais je ne vois pas pourquoi ca me donnerait autre chose que disk_free_space...

je comprend rien (comme d'hab ;-) )
si je fait ca:

ca me donne ca:
1912 . system('du -sk') = 1912 .disk_free_space(/home/sites) = 20759494656disk_total_space(/home/sites) = 27564351488

/home/sites correspond peut etre au repertoire home contenant tous les sites de l'espace mutualisé

parce que c'est l'espace restant sur le répertoire.
les quotas, c'est encore autre chose. (mais je sais pas comment on demande en php)