Moyenne en secondes entre 2 datetime

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

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

Code:

---

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.

Citation:

---

Envoyé par sabotage

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

Citation:

---

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.

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.

:ccool:

Citation:

---

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

Citation:

---

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

---

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

Citation:

---

Envoyé par sabotage

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 ? :mrgreen:

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

Code:

---

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

---

CQFD !

Citation:

---

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

Citation:

---

CQFD !

---

Pas de ma faute si le terme "champs" est aussi utilisé.
J'ai même trouvé que

Citation:

---

SHOW FIELDS est un synonyme de SHOW COLUMNS.

---

Pour le problème NULL (Mysql accepte les NULL pour les colonnes Datetime), c'est effectivement intéressant comme approche.
Je n'ai jamais vu un découpage de données aussi poussé dans une structure de bdd.

Ca marche à merveille! Merci ;)

Attention c'est avg() et non average() la bonne syntaxe.

:ccool: