Discussion :

[Invité2]

Re-bonjour,

J'ai fais un chat tout simple en php/ajax.
J'aimerais le transformer en multi utilisateurs.
Je ne vois pas trop comment gérer les messages en mode multi users car dans le chat tout simple, il suffit d'aller chercher tous les messages. Dans le cas du multi users, il faut ajouter un champ "conversation"(c'est un exemple) à la table "messages"
Je peux créer une table "conversation" avec les noms des utilisateurs concernés.

Et après ? je fais comment pour mettre a jour les fenetres de chat ?
- Chaque fenetre ouverte a l'id de la conversation ?
- Quel genre de requete faut il envoyer pour savoir si quelqu'un commence une nouvelle discussion avec quelqu'un d'autre ?

Je ne sais pas si je suis clair là....

des idées ?

Merci.

[Benjamin Delespierre]

Hello

Deux solution:
- soit tu prends ajaxIm et tu te casse pas la tête
- soit tu réalise une structure de bdd qui ressemble à ça:


Pour la mise à jour, c'est assez simple, tu envoies toutes les x millisecondes un XHR vers un web service PHP qui interroge "messages_has_recipients" pour obtenir les id des nouveaux messages (status read à false) pour un recipient donné. Et tu vas chercher les messages avec un autre webservice (tous les message d'un coup bien entendu). Tu fais transiter tout ça avec du JSon et ça roule tout seul :p

Après, pour éviter que la table de messages ne grossisse trop, tu colles un cronjob qui est chargé de supprimer toutes les entrées de messages qui dépassent un certain timestamp (par exemple, message de plus de 20 minutes) ou bien tu les archives dans une table d'archivage.

[Invité2]

merci,

Je vais étudier ton schéma.

[Benjamin Delespierre]

Voici la représentation MySQL du schéma:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
 
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';
 
CREATE SCHEMA IF NOT EXISTS `chat` DEFAULT CHARACTER SET utf8 ;
USE `chat` ;
 
-- -----------------------------------------------------
-- Table `chat`.`conversation`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `chat`.`conversation` (
  `id` BIGINT(25) NOT NULL ,
  `name` VARCHAR(45) NOT NULL ,
  `password` VARCHAR(45) NULL ,
  PRIMARY KEY (`id`) )
ENGINE = InnoDB;
 
 
-- -----------------------------------------------------
-- Table `chat`.`users`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `chat`.`users` (
  `id` BIGINT(25) NOT NULL ,
  `name` VARCHAR(45) NOT NULL ,
  `users_id` BIGINT(25) NOT NULL ,
  PRIMARY KEY (`id`) )
ENGINE = InnoDB;
 
 
-- -----------------------------------------------------
-- Table `chat`.`messages`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `chat`.`messages` (
  `id` BIGINT(25) NOT NULL ,
  `conversation_id` BIGINT(25) NULL ,
  `body` VARCHAR(250) NOT NULL ,
  `time` BIGINT(25) NOT NULL ,
  `author` BIGINT(25) NOT NULL ,
  PRIMARY KEY (`id`) ,
  INDEX `fk_messages_conversation1` (`conversation_id` ASC) ,
  INDEX `fk_messages_users1` (`author` ASC) ,
  CONSTRAINT `fk_messages_conversation1`
    FOREIGN KEY (`conversation_id` )
    REFERENCES `chat`.`conversation` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_messages_users1`
    FOREIGN KEY (`author` )
    REFERENCES `chat`.`users` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
 
 
-- -----------------------------------------------------
-- Table `chat`.`messages_has_recipients`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `chat`.`messages_has_recipients` (
  `messages_id` BIGINT(25) NOT NULL ,
  `users_id` BIGINT(25) NOT NULL ,
  `read` TINYINT(1)  NOT NULL DEFAULT FALSE ,
  PRIMARY KEY (`messages_id`, `users_id`) ,
  INDEX `fk_messages_has_users_users1` (`users_id` ASC) ,
  INDEX `fk_messages_has_users_messages1` (`messages_id` ASC) ,
  CONSTRAINT `fk_messages_has_users_messages1`
    FOREIGN KEY (`messages_id` )
    REFERENCES `chat`.`messages` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_messages_has_users_users1`
    FOREIGN KEY (`users_id` )
    REFERENCES `chat`.`users` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
 
 
 
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

Si ça peut servir...

[Invité2]

Merci, mais j'arrive un peu tard, j'ai déjà effectué le plus gros du travail.

J'ai crée deux tables :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
CREATE TABLE IF NOT EXISTS `chat_messages` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `talkId` int(11) NOT NULL,
  `message` varchar(255) NOT NULL,
  `date` bigint(60) NOT NULL,
  `fromUser` varchar(60) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
 
CREATE TABLE IF NOT EXISTS `chat_talk` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `users` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

je n'ai pas vraiment respecté vos conseils mais j'essaye d’alléger le code et surtout les requêtes au maximum.

Il ne me reste plus qu'a finir ma fonction pour récupérer les messages. Et je galère avec les tableaux.

[Benjamin Delespierre]

Plusieurs remarques:
- le champ date s'apparente plus à un timestamp, tu devrais le renommer.
- le champ fromUser devrait être une clé étrangère ciblant le champ id de la table users
- le champ users de chat_talk est absolument immonde. Enlève-moi ça et mets une relation n-m entre users et chat_talk.

De plus
- Quel est l'intérêt de mettre ces tables en MyIsam ? On perds la sécurité en plus.
- Quels sont les problèmes de requêtes que tu rencontres ?

je n'ai pas vraiment respecté vos conseils mais j'essaye d’alléger le code et surtout les requêtes au maximum.

Bien au contraire, avec une structure pareille tu alourdis considérablement les requêtes et d'une part tu dégrade les performances d'autre part tu augmente la mémoire physique occupée par les tables en en respectant pas les formes normales.

[stealth35]

- Quel est l'intérêt de mettre ces tables en MyIsam ? On perds la sécurité en plus.

toujours être le plus agnostique possible

[Benjamin Delespierre]

toujours être le plus agnostique possible

Alors là j'ai rien compris

[stealth35]

Alors là j'ai rien compris

peut importe ton SGBD ton système doit marcher

[Invité2]

Ah oui j'ai oublié de le renommer de champ date.

Que ce passe t'il avec le champ users de chat_talk ?
Cela me permet d'avoir les utilisateurs concernés dans le même champ,
et je fait mes vérifications avec :

Code :

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

1
2
3
4
 
$param = array('userId'=>$userId);
$query ="SELECT id FROM ".$this->__get('db_prefix')."_chat_talk WHERE FIND_IN_SET(:userId, CONCAT(users,','))";
$data = $this->GetDb()->read($query,$param);

[Benjamin Delespierre]

Que ce passe t'il avec le champ users de chat_talk ?
Cela me permet d'avoir les utilisateurs concernés dans le même champ,

C'est justement ça qui ne va pas, ça va à l'encontre des règles élémentaires de conception: http://en.wikipedia.org/wiki/First_normal_form
Plus le nombre d'entrées dans cette table va grandir et plus les requêtes vont se dégrader en performances.

Maintenant tu fais ce que tu veux.

[Invité2]

Vous avez raison, j'ai presque fini, alors je vais finir histoire d'avoir un truc(potable) qui fonctionne. Mais, je ferais des modifications dès que j'ai un peu de temps car j'aimerais avoir un code qui respecte "les règles de conception"

En fait, j'aurais du faire la table "talk" comme la table "Customer Telephone Number" du lien que vous m'avez donné("A design that complies with 1NF")

Et, je vais passer mes tables en "InnoDB".

Merci pour votre aide

[Benjamin Delespierre]

Et, je vais passer mes tables en "InnoDB".

Du temps où je faisait mes études, notre prof d'ACSI nous disait "par défaut, mettez InnoDB et changez-en selon les besoins..." Curieusement c'est resté

Au prix d'une (assez conséquente il faut l'avouer) augmentation de volume, on gagne les transactions et les contraintes (pour l'essentiel). C'est indispensable d'avoir un modèle blindé pour éviter qu'un oubli au niveau du code ne viennent insérer des doublons ou pire des orphelins...

Pour ce qui est des formes normales, on considère qu'un modèle est correct à partir de la forme BCNC (Boyce-Codd Normal Form ou 3.5NF). Un modèle qui respecte ce standard est non redondant, performant et moins gourmand en ressources.

[Invité2]

eh eh , j'ai pas eu la chance de faire des études, j'apprends sur le tas...

Je vais chercher de la doc sur Boyce-Codd Normal Form.
Pour ceux que cela intéresse :
Boyce-Codd Normal Form

Bon, mon tchat est fini, ca fonctionne, en tout cas ca a l'air de fonctionner.
J'en ai un peu bavé pour gérer les suppressions de talk et message lors des unload, ready, etc...

Bah maintenant que je me suis bien pris la tête, je vais revoir mes tables....
oui oui , je fais rien comme tout le monde lol

Merci pour votre aide.