Discussion :

[Sayrus]

Bonjour,

J'ai Deux tables.

Dans l'une est stocké en datetime le jour et l'heure de création d'un envoi.
Dans l'autre table est stocké en datetime le jour et l'heure de la réponse à cette envoi et l'id de l'user qui a répondu.

J'ai donc plusieurs enregistrements et il me faudrait pouvoir sortir la moyenne du temps de réponse entre l'envoie d'une offre et le moment ou elle a été répondue.

Toutes les offres n'ont pas forcément de réponse. Pour que le résultat soit juste, il faut se baser uniquement sur les offres répondues pour obtenir la moyenne.

Table1 : id | dateEnvoi (datetime)
Table2 : id | userId | dateReponse (datetime)

Merci beaucoup

[sabotage]

Est-ce que c'est légitime d'avoir deux données si proches en nature dans deux tables différentes ?
Mais sinon

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

average(UNIX_TIMESTAMP(date2) - UNIX_TIMESTAMP(date1))

devrait fonctionner
Je suppose qu'il manque des champs dans la structure que tu nous montres sinon tu vas avoir du mal a faire la jointure entre les deux tables.

[CinePhil]

Est-ce que c'est légitime d'avoir deux données si proches en nature dans deux tables différentes ?

Son modèle de données est au contraire excellent !

Un envoi peut avoir une réponse et une réponse concerne un envoi.

envoi -0,1----avoir----(1,1)- reponse

Je suppose qu'il manque des champs dans la structure que tu nous montres sinon tu vas avoir du mal a faire la jointure entre les deux tables.

Les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de colonnes et de lignes.

Et la jointure se fait probablement sur la colonne id des deux tables, c'est à dire l'identifiant de l'envoi.

[Sayrus]

Merci pour vos réponses!

Cela semble répondre à ma demande mais je ne pourrai confirmer ça que ce soir.

Je vous tiens au courant pour voir si cela à bien réglé mon problème.

[sabotage]

Les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de colonnes et de lignes.

Le mot "champs" est utilisé dans la documentation PHP, dans la documentation Mysql, même dans la FAQ Mysql sur developpez ; je l'utilise peut être mal mais de la a faire croire que ça n'a pas de rapport avec les bases de données ...

Son modèle de données est au contraire excellent !

A part dans l'idéologie quel est l'avantage de ce découpage ?

[CinePhil]

Dans la documentation PHP et dans la documentation PHP, le mot "champs" est utilisé un peu partout.

Tu as lu la documentation PHP deux fois ?

Comment ajoutes-tu ce que tu appelles "un champ" à une table SQL ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER TABLE la_table
ADD COLUMN la_colonne -- + paramètres

CQFD !

A part dans l'idéologie quel est l'avantage de ce découpage ?

De ne pas laisser le bonhomme NULL envahir la BDD, ce qui nuit aux performances dès que le volume de données devient un peu conséquent.
En plus, avec le mauvais MySQL, les dates nulles ne le sont pas vraiment puisque la valeur affichée par défaut est plutôt la date inexistante '0000-00-00'.