fonction pour construction de clés, approximation de dates

:salut:

dans un table de type

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

CREATE TABLE MaTable ( id int(11) autoincrement subject VARCHAR(255), creation_date DATETIME, CONSTRAINT PRIMARY KEY (id) autoincrement ) # je la fais à la volée rapido, probable que l'executer génère une erreur :)   # on met qqs valeurs INSERT INTO MaTable (subject, creation_date) VALUES ('salut bla bla bla', now()) INSERT INTO MaTable (subject, creation_date) VALUES ('autre conversation XCV', now()) INSERT INTO MaTable (subject, creation_date) VALUES ('salut bla bla bla', now()) INSERT INTO MaTable (subject, creation_date) VALUES ('salut bla bla bla', now()) INSERT INTO MaTable (subject, creation_date) VALUES ('autre conversation XCV', now()) INSERT INTO MaTable (subject, creation_date) VALUES ('autre conversation XCV', now())

---

bref, j'ai bcp de lignes qui ne font sens que ensemble (des conversations quoi)

malheureusement, la simple égalité sur le champ subject ne suffit pas parce qu'il arrive de temps en temps que le mm subject ressorte dans les semaines/mois qui suivent.
donc je voudrais faire un champ calculé qui soit la concaténation de 'subject' et une valeur calculée sur la date. cette valeur serait genre une autre date qui soit +/- égale à celle du sujet (disons une fenetre de 3 jours avant 3 jours apres)

de sorte que derrière, je puisse faire une view avec un group by sur ce_champ_calculé qui me ferait 1 ligne = 1 conversation

c'est sur la manière de calculer "ce truc à peu près égal à la date à qqs jours près" je coince.

si je mets par exemple "le plus proche lundi", je vais avoir des effets de bord, du genre les conversations qui se déroulent entre le jeudi 11h30 et 12h30, la moitié sera sur le lundi d'avant, l'autre moitié sur le lundi d'apres. donc 2 clés différentes pour la mm conversation...

vs avez une idée pour monter ce champ ?

j'y ai pas mal refléchi et je crains qu'il n'y ait un pb mathematique là dessous

concrètement, si on veut qu'une suite continue de nombres (par exemple que tous les datetime entre maintenant et dans 2j) ait le mm résultat, mais que ce résultat ne soit pas le mm qqsoit l'entrée

==> alors necessairement la fonction devient discontinue

or une fonction discontinue implique forcément qu'il va exister des valeurs proches qui vont avoir un résultat différent. des effets de bord quoi


non ?

Salut,

As tu une PK autoincrémentée sur ta table ? si non il faut en créer une et référencer les réponses via l'id du message origine :
matable (id,subject,creation_date,id_origine).

Code:

---

1 2 3 4 5 6

INSERT INTO MaTable (id,subject, creation_date,id_origine) VALUES (1,'salut bla bla bla', now(),NULL) INSERT INTO MaTable (id,subject, creation_date,id_origine) VALUES (2,'autre conversation XCV', now(),NULL) INSERT INTO MaTable (id,subject, creation_date,id_origine) VALUES (3,'salut bla bla bla', now(),1) INSERT INTO MaTable (id,subject, creation_date,id_origine) VALUES (4,'salut bla bla bla', now(),1) INSERT INTO MaTable (id,subject, creation_date,id_origine) VALUES (5,'autre conversation XCV', now(),2) INSERT INTO MaTable (id,subject, creation_date,id_origine) VALUES (6,'autre conversation XCV', now(),2)

---

Pour avoir la liste des discussions origines :

Code:

---

select * from matable where id_origine is null order by cration_date;

---

Pour obtenir les messages composant une discussion précise :

Code:

---

1 2 3 4 5 6 7 8 9 10

select * from (select id,subject,creation_date,1 as origine from matable where id=5 union all select id,subject,creation_date,2 as origine from matable where id_origine=5 ) order by origine,id

---

Par contre je ne connais pas de solution mysql pour faire des requêtes hiérarchiques.

Citation:

---

Envoyé par skuatamad

Salut,

As tu une PK autoincrémentée sur ta table ? si non il faut en créer une et référencer les réponses via l'id du message origine :
matable (id,subject,creation_date,id_origine).

---

oui c'est vrai que j'ai écrit le create à l'arrache, mais dans l'idée id est bien la PK autoincrementée de la table.

quant à id_origine (le id du 1er message) et bien précisément c'est bien ca le pb.

===> il n'y en n'a pas.

je n'ai pas de controle sur le format de la table, ni sur le format des données. et en l'état il n'y a pas de id_origine pour faire office d'identifiant de conversation. Tout ce que je peux faire c'est interpréter le champ subject et le champ creation_date pour en déduire que ce sont des conversations.

ou alors je n'ai pe pas compris qqch ds ton msg... :oops:


de toute facon, je pourrais faire une jointure sur la table elle-meme avec une condition de type

t1.subject = t2.subject AND (t1.creation_date -2 days, t1.creation_date + 2 days) OVERLAPS (t2.creation_date, t2.creation_date)

le truc c'est que j'aurais préféré éviter cet espece d'algo en n*n (pour chaque ligne de la table il faut re-scanner toute la table)

pour favorsier un algo en n : chaque ligne calcule son propre champ-clé-conversation sans regarder les autres lignes. Et là je pense qu'il y a un souci mathematique derrière en fait... :'(


on dirait que OVERLAPS n'est pas supporté avec mysql5... => http://www.developpez.net/forums/d60...our-mysql-5-a/ mais bon il doit etre possible de faire un equivalent moins lisible