sflavier
commented
10 months ago La table corresp_sets n'est pas obsolete : seuls les champs src, rec et phn le sont. Les informations précédemment stockées (sauf src car identique la source du rec) dans ces champs se trouvent maintenant dans la table cognate_fragments, et le liens entre ces fragments est dans la table liens_fragments_corresp ( et cette table permet de voir les correspondance obsolete en cas de changement ... en théorie)
la seule information "perdue" est la src. Il faut également considérer la table alignements : un cognat peut maintenant avoir plus d'un alignement.
pour retrouver les informations à partir d'un cognat :
SELECT * FROM liens_fragments_corresp lfc, cognate_fragments cf, corresp_sets cs, alignements a WHERE cs.id=lfc.id_corresp AND lfc.id_cognate_fragments=cf.id_cf AND cf.id_algn=a.id AND a.id_recordset=30621 ORDER BY lfc.col ASC
cette requête présentera les alignements de tous les utilisateurs (les champs id_user et visibility de la table alignement gérent les droits) et le champs obsolete indique les fragments/corresp qui ne sont pas actifs dans l'alignement sauvegardé (trace des changements).
normalement tout est en base. Si tu as des demandes spécifique on peut en discuter.
La table corresp_sets semble ne pas se mettre à jour lorsqu'on ajoute une fiche dans un cognat et dans un alignement. Peut-être que cette table n'est plus vraiment utilisée (c'est pour ça qu'on ne s'en rend pas compte), mais il se trouve que je m'en sers pour une expérience, et ce bug pose problème. Si tu me dis que la table est obsolète, je trouverai un moyen de contourner la difficulté...