Programmation d'une mini-messagerie sur la base d'un code que je ne comprend pas...

[z3d]

[...] en premier lieu tu ne devrait pas avoir le nom de l'emetteur ni celui du recepteur dans ta table Message.
Il faut que tu emploies des ID pour cela. Je t'encourage à aller voir le site du Zéro pour ce principe. [...]
kéké.

En fait, en premier lieu dans la phase de modélisation il est vrai qu'on utilise les ID des membres pour connaitre les destinataires et les expéditeurs.

Cependant, lorsque l'on passe à la phase d'optimisation on ajoute les pseudos car cela permet d'éliminer une double jointure couteuse en ressource. En contrepartie, la taille de la BDD augmente un peu mais de façon minime par rapport au gain de performance.

Wahou...

Je vais être moins gentil que Mr Anthor :non:

On entends tout et n'importe quoi... :mauvais:

Et l'intégrité des données que tu stockes ?

Un seul conseil ! Un p'tit tour du côté de chez developpez.com : PETIT COURS SUR LES SGBDR

[Amrac]

Pour optimiser tu dois t'adapter au contexte.
L'intégrité est quelque chose d'important en temps normal, mais ici le pseudo d'un joueur ne change jamais, il n'y as donc pas de problème.

Une optimisation n'est jamais que du bénéfice, il y a toujours du gain et de la perte.

Plutôt que de dire qu'on entend tout et n'importe quoi, explique ton point de vue.

Ici, si tu dois absolument maintenir l'intégrité des données sur les pseudos, alors les très rares fois ou tu modifie le pseudo tu dois aussi modifier la table de la messagerie, ce qui est je le conçois plus couteux.

On alourdit donc la mise à jour d'un pseudo, ce qui est très rare. Mais on gagne énormément pour l'affichage de la messagerie.
Pour ce qui est de l'alourdissement de la base de données, cela représente l'équivalent de 2 mots de plus par message, ce qui est négligeable.

[Lanwin]

Ce que je n'ai pas compris personnellement, c'est ça :

Par contre une petite rectification: il est (a priori) inutile de garder le pseudo de l'expéditeur car on ne l'utilise jamais, a moins d'avoir une "boite d'envoi".

Il faut bien que celui qui reçoit le message sache qui lui envoie, non?

Amicalement,

[z3d]

Mon point de vue je l'ai déjà donné et c'est un cours sur les SGBR vers lequel je renvoie.

Maintenant si pour récupérer des messages on optimise en utilisant des chaînes de caractères dans la clause WHERE moi je veux bien faire le tour du monde en ballon en prêchant la bonne parole :heuuu:

Sinon un p'tit rappel sur la compléxité des algorithmes de sélection d'un sgbdr :

Sélection, Projection (sans élimination des doublons) ===> O (n)
Projection (avec élimination des doublons)
Union, Jointure, Semi-jointure, Quotient, Opérations de mises à jour ===> O (n*log n)
Produit Cartésien ===> O (n²)

Faudrait peut être arrêter de croire qu'en faisant des pseudos optimisations pour éviter des jointures est la solution miracle surtout quand on voit sa compléxité.

Il faut bien que celui qui reçoit le message sache qui lui envoie, non?

Tout à fait et pour ce faire tu stockes l'identifiant de l'expéditeur et du destinataire.

[Ter Rowan]

Maintenant si pour récupérer des messages on optimise en utilisant des chaînes de caractères dans la clause WHERE moi je veux bien faire le tour du monde en ballon en prêchant la bonne parole :heuuu:

l'éventuel intérêt d'intégrer le nom (label) en plus de l'id dans la table de faits n'est pas tant pour faire une recherche que de ramener directement une information complémentaire, sans jointure, alors même que la clause where continue de se baser sur l'id.


après le seul sujet, c'est de voir le nombre d'enregistrement de la table de référence

si y a 15 références aucun intérêt à cette 'optimisation'
si y en a 1 milliard, je pense que ça en a un

entre les deux.... ben ça se discute ^^

et si jamais le label bouge souvent, alors là oui, il ne faut vraiment pas le laisser dans la table de faits, trop de ressources seraient nécessaires pour maintenir une intégrité référentielle (sauf si on admet qu un vieux message reste avec le vieux label, ça peut être justifié)

tout dépend des situations. A mon sens on devrait commencer par un bon modèle "puriste", robuste, et simple et après voir, où cela mérite de faire autre chose

[Amrac]

Presque personne n'as compris ce que j'ai voulus dire, je vais donc essayer d'être plus clair.
En même j'aide pas en inversant mes mots, quand je parlais du pseudo inutile je voulais parler du destinataire et non pas de l'expéditeur

Dans une table de base pour une messagerie, vous avez:

ID || IDDestinataire || IDExpediteur || Objet || Message.

C'est un système qui fonctionne très bien, sauf pour la sélection des messages. Le cas typique est celui ou on veut afficher le pseudo de l'expéditeur et l'objet du message, afin de sélectionner le message que l'on souhaite lire. (Comme lorsqu'on lit ses emails).

Si vous avez un site de moyenne taille, avec par exemple 15 000 membres et 300 000 messages (20 messages par membres). Le SGBD doit d'abord sélectionner les 20 messages puis aller chercher les 20 pseudos qui correspondent au sein d'une table de 15 000 entrées.

Comme le dit z3d, avec une complexité de O(n*log n) c'est une requête très lente.

Le principe d'optimisation est très simple, il suffit d'ajouter le pseudo de l'expediteur dans la base, on obtient donc cela:

ID || IDDestinataire || IDExpediteur|| PseudoExpediteur || Objet || Message.

Les opérations annexes comme l'ajout/suppression/affichage d'un message ne sont pas affectés.
Mais maintenant, lorsque l'on veut afficher les messages il n'est plus nécessaire de faire de jointure puisque l'on à déjà l'information dans nos tuples.

On fait donc une simple sélection/projection, cette simple optimisation nous permet d'obtenir une requête en O(n) plutôt qu'en O(n*log n).
Sans oublier que l'affichage de la messagerie est un point par lequel tout le monde passe. Il s'agit de la requête la plus demandé, et donc la plus importante à optimisé.

Pour l'intégrité référentielle, il est clair que dans le cadre d'une messagerie le changement de pseudo est quelque chose de rare et exceptionnel.

Je me suis peu être pas super bien exprimé, mais j'ai pas l'impression que tu as fait des efforts pour comprendre z3d.

En gros:

On entends tout et n'importe quoi... :mauvais:

Et l'intégrité des données que tu stockes ?

A l'avenir fait l'effort de regarder le contexte.

Maintenant si pour récupérer des messages on optimise en utilisant des chaînes de caractères dans la clause WHERE moi je veux bien faire le tour du monde en ballon en prêchant la bonne parole :heuuu:

Fait un effort pour éviter de te foutre de la gueule des gens pour rien. Plutôt que de parler de, je cite "faire le tour du monde en ballon en prêchant la bonne parole :heuuu:" tu aurais pus prendre la peine de lire 4 messages au dessus:

Tu garde l'ID car il est très rapide pour la sélection dans la base, mais tu garde aussi les pseudos.

Est-ce que je dois vraiment expliquer cette phrase: "Tu garde l'ID car il est très rapide pour la sélection" ?
Et si tu avais la flemme de lire mon reply, tu pouvais lire ce qu'avais posté keke et Bladrak juste avant:

D'où l'intérêt de mettre les deux non ? (id + pseudo dans la même table)
Comme ça on fait une recherche par ID et on choppe le pseudo simplement

Dans la table messagerie tu veux que tu as :
id_emetteur
nom_emetteur
id_recepteur
nom_recepteur

C'est bien cela ? Afin d'éviter une recherche ?

[z3d]

Je suis désolé si tu prends ma remarque comme du "foutage de gueule" ce qui n'est pas le cas.
Mais je reste campé sur ma position ajouter en plus le pseudo pour éviter une jointure n'est pas une optimisation !

[Shivaan Keldon]

perso, je pars du principe qu'un pseudo ne change jamais. je n'en vois pas l'intérêt. donc je n'ai aucun id, car les pseudos SONT les clés de mes tables user

à partir du moment ou tout est géré par pseudo, ça simplifie tout

c'est vrai après tout. pourquoi tout le monde s'acharne à faire des clés de type integer auto incrémentables. la seule règle pour une clé primaire, c'est d'être unique. ce qui est le cas des pseudos. donc faites des varchar comme clé de vos tables quand cela est utile ^^

[Shivaan Keldon]

tu m'expliques ou est la différence de récurrence entre 11111 comme id et "pouet" ?

de plus, la taille des objets à manipuler est assez minime. je dis pas, y'a 20 ans, quand les ordis avaient 16k de RAM, là fallait regarder à optimiser. maintenant, la différence entre manipuler un int ou un varchar est vraiment minime. d'autant qu'un pseudo fait rarement plus de 15 caractères et que le principe même du varchar est de ne garder que ce qui est stocké (exit les vides)

et enfin, si c'était une règle absolue, toutes les bdd imposeraient l'int comme id. ce qui n'est pas le cas. c'est tout au plus une convention datant d'il y a plus de 20 ans. donc bon, faut évoluer un peu. si ça peut tout faciliter d'avoir un id en varchar, je vois pas pourquoi persister avec les int

[Flag62]

+1 Plume, c'est plus optimisé avec des ID int et c'est également plus pratique quand tu dois rattacher ton utilisateur à quelque chose
Sur un jeu, à la limite ton ID int ne depassera jamais une taille de 5 caractères (99999 joueurs) ou alors tu as un jeu de ouf... par contre tes pseudos, peuvent aller jusqu'à 15 caractères et si tu multiplie par un grand nombre d'enregistrement bah bon courage...tu vas consommer de l'espace et de la bande passante pour rien...
J'utilisai les pseudos de mes utilisateurs en clé primaire avant, et j'ai arrété c'est vraiment pas pratique quand tu utilise ton ID Pseudo comme clé étrangère et qu'en plus tu as un grand nombre d'enregistrement...