[Stratégie] faire un update dynamique !

salut.
j'ai une application qui gère une base de données. et je dois avoir une table qui affiche les données d'une table ...et le problème ce que cette table doit être régulière mise a jour ( a chaque nouvelle entrée ).
alors je me demande s'il y a que le sgbd (mysql) me signale qu'une nouvelle entrée est faite ?
si non comment je peux faire une mise à jour automatique (chaque 10 secondes par exemple) ? et dans ce cas , est ce que cela ne pose de problemes( grosse consommation de mémoire etc) ...surtout si plusieurs clients peuvent accéder a la base de données ?
merci

Si tu travaille avec oracle, tu peux mettre un trigger sur la table qui met à jour automatiquement une colonne lors des insert/update, tu met dans cette colonne le contenu d'une séquence oracle (çà fait que grandir ces trucs), ensuite, dans ton programme:

tu fait un select de "tout" (point de départ)
ensuite, régulièrement, tu fait un sélect avec un critère sur ladite colonne pour ne prendre que ce qui est plus grand que X, X étant le max de ton select précédent

ainsi, t'as un select uniquement sur ce qui a été modifié / ajouté. Par contre, pas de solution pour les delete de ce coté là.

merci tchize_ mais j'utilise mysql ( je suis obligé ).
donc je dois me tourner vers les timers ?

si tes données sont nombreuses, faut trouver un moyen de limiter les select (je connais pas assez les spécificités de mysql), sinon, des timers réguliers devraient être ok

Voila comment je ferais, pour régler le problème.

Prérequis : Une table avec les users et leur status (connecté/Déconnecté)
Une table ModTable qui référence les modifications faite à la table TABLE.

La y a deux cas possible, soit tu as vraiment beaucoup de user, soit t'en as pas beaucoup.

Solution 1: pas beaucoup de users

La table ModTable est remplis par un trigger qui pour tous les entrées faite (ou modifier, ou supprimer) dans la table TABLE remplis une ligne pour chaque users connecté.

Tu vas donc avoir un jeu d'enregistrement du type :
REFMATABLE,REFUSERS,TYPEMOD
Avec :
REFTABLE la clé primaire de TABLE,
REFUSERS, la clé primaire de USERS,
TYPEMOD le type de modification.

Un index sur REFUSERS.

A chaque fois qu'un utilisateur se deconnecte il vide ces entrée de la table MODTABLE

A chaque fois qu'un utilisateur se connecte il vide ces entrées de la table MODTABLE (cas ou il se sera déconnecté malproprement), et il charge tous les lignes de MATABLE en mémoire.

A chaque tic que rafraichissement, (a toi de voir tous les combien de temps) dans une transaction tu fait un select de la table MODTABLE avec une jointure sur la TABLE, puis tu éffaces les lignes concernant ce users de la table MODTABLE. Tu connaitras les types de modifications.

L'inconvienient de cette solution c'est qu'a chaque fois que tu crées une ligne dans ta table TABLE tu en crées autant que de users connecté dans la table MODTABLE


Solution 2 : Beaucoup de users, et vas demander un plus d'espace.

le principe est globalement le même sauf qu'on vas géré les dates de création modification et de suppression, au lieu de géré une ligne pour chaque users. on auras donc une table MODTABLE qui référence les modifications faite à la table TABLE et remplis par un triggers.

Tu vas donc avoir un jeu d'enregistrement du type :
REFMATABLE,TIMESTAMPMOD ,TYPEMOD
Avec :
REFTABLE la clé primaire de TABLE,
TYPEMOD le type de modification.
TIMESTAMPMOD la date de modification.

A chaque fois qu'un user se connecte il me a jour la timestamp dans son profile (un champ qui correspond a ça dernière consultation dans la table users). il recupère l'intégralité des donnée de la base.

A chaque tic que rafraichissement, (a toi de voir tous les combien de temps) dans une transaction tu fait un select de la table MODTABLE avec une jointure sur la TABLE avec une clause where TIMESTAMPMOD >= TIMESTAMP, suivit d'un update sur le la table user pour mettre a jour la colone timestamp

Le problème restant c'est que ta table MODTABLE vas vite être tres grosse. Un solution est de la purgé des entrés plus utilise en fesant une supression de tous les lignes dont les utilistateurs n'ont plus besoin. c'est à dire tous les lignes dont le TIMESTAMPMOD est < au plus petit TIMESTAMP

Dans les deux cas.

Dans ton triggers il faudra tenir en fonction de comment tu veux rendre compte des modifications à tes programmes clients :
Es-que je supprime les lignes d'insertion si je fait un mise a jours ? Es-que je supprime les lignes d'insertion et mise a jours si je fait une suppression de cette ligne.

Si tu veux faire des select avec des clause where sur ta table tu devrai le faire aussi lors de ta jointure sur la table MODTABLE

Merci ITCsoft54 pour ce bon tuto :)

je crois que je suis dans le 1 er cas ...mais je trouve que la 2eme solutions est vraiment très bonne !
Mais je me pose quand même cette question :
si j'ai bien compris on réduit la quantité de données apporté par les requêtes mais on ne réduit pas le nombre de ces requêtes en question (puisque on doit a chaque fois faire une requête pour vérifier si'l ya changement) !!
donc le nombre d'accée a la base reste le même !!

j'ai juste une petite idée sur les triggers sous oracles mais sous mysql j'ai jamais travaillé avec :aie:
mais je crois que c'est bien le moment pour que je les maitrise :roll:
merci encore une fois