Je suis pas sur que le AS de cette façon soit géré par tous les SGBD.

Sinon es tu sur d'avoir corrigé partout ? c'est le seul endroit ou y a la fonction INSERT pour cette table?

Je pence pas que Geno est fait plusieurs functions pour la méme choses ..

Donc j'ai une petite table de 1231 Ko
avec plus de 32 000 enregistrements..
Après execution je passe à 3.259 Ko

Mais cela peut beaucoup changer, tout dépend en faite dans la façon dont ta table a été rempli. Si aucun de tes membres sont revenus plusieurs fois sur un sujet, ça risque de faire tres peu de difference.

Il existe des méthodes plus simples pour gérer le marquage des sujets comme lus Et pas plus lourdes

Comme quoi par exemple ?

Oui c'est bien beau de dire ça, mais développé ton idée pourraît être bien

De toute façon les deux seules façon viables de gérer des non lus sont soit avec des cookies, soit de cette façon. Et la solution des cookies a ses inconvénients assez pénibles ...

Un cookie ne peut être utilisé correctement.

Suffit que la personne vide ses cookies ou change de poste de travail (maison/boulot) pour avoir à relire les même sujets.

Stocker dans une base de donnée, les posts qu'un utilisateur a lu pourquoi pas.
Par contre y a un truc auuquel je ne sais pas à quoi ça sert rélllement.
Quel intérêt de mettre la colonne forum_id dans cette table?
A la limite on a juste besoin de :

user_id, sujet_id, derniere_visite

Je crois que c'est pour éviter une requète suplémentaire au niveau de l'index du forum, pour afficher les forums lus et non lus. En ayant le forum_id, t'as pas besoin de faire une requète sur la table sujet pour réqupérer le forum_id pour pouvoir verfifier le status des forums que tu affiche

Et bien par exemple tu peux stocker dans la table sujet un champ sujet_membres_lu qui contiendrait les id des membres ayant lu le sujet, de cette façon il est assez facile de faire un système de marquage performant par catégories, par forums (en incluant les sous forums) et etc ... et il est donc encore plus simple de vérifier si le membre a lu le sujet ou pas

Hum ça obligera soit à dupliquer les lignes de sujet dans cette table en fonction du nombre de membre OU contacténé tous le membres dans un champ.

Et la 2 ième méthode n'est pas forcément la plus rapide, car il faut splitter et parser ensuite cette chaine

C'est tres bien comme sa, juste il faudrai transphormer les colonnes 'user_id, sujet_id, forum_id' en primary key sa accelleré le bin's ( le mieux sa serait une foreign key)

Heu.... UNE clé primaire par table, jamais deux. Ensuite, Foreign key n'accélère rien du tout, ça sert à lier deux tables. Et si on mets une colonne en clé primaire, il ne faut pas la mettre en index (normalement, on mets l'id en clé primaire, et on indexe les trucs spéciaux).

Midori.

lol

Déjà les procédures pour vérifier si un membre a lu le sujet, et pour ajouter le membre au sujet seraient assez pénibles puisqu'il faut concatener des chaines.
Ensuite ton système marchera pour un forum limité en membre puisque la taille d'un champ est limité.
Enfin c'est super lent comme méthode Les jointures sont beaucoup plus rapides que l'accès en écriture direct à un champ TEXT.

et bien ma foi en test ça rend pas mal, et dans un forum il y a généralement moins de membres que de sujets

Pour un forum tout petit on est d'accord ca peut marcher. Mais dès qu'il grossira ca deviendra le bordel dans la base de donnée .. Enfin bon comme tu veux mais si personne n'utilise un tel système ya surement une raison