Conception de base de données pour les révisions de texte

This question contient une excellente couverture de la conception d'un schéma d'historique/de révision de base de données pour des données telles que des nombres ou des champs à choix multiples.Conception de base de données pour les révisions de texte

Cependant, il n'y a pas beaucoup de discussion sur les grands champs de texte, comme on le trouve souvent dans les systèmes de type blog/Q & A/wiki/document. Par conséquent, qu'est-ce qui serait considéré comme une bonne pratique pour stocker l'historique d'un champ de texte dans un système d'édition basé sur une base de données? Le stocker dans la base de données est-il une bonne idée?

Source

2009-04-15 John McAleely

Je suppose que vous vouliez intégrer un lien ("Cette question contient ...") alors s'il vous plaît modifier votre message et l'inclure. –

Le formatage de lien a été corrigé. – Cerebrus

Je développe un moteur wiki et les révisions de page/article sont stockées dans une table de base de données. Chaque révision a un numéro de révision séquentiel, tandis que la révision "actuelle" est marquée par -1 (juste pour éviter la valeur NULL).

Le texte de révision est stocké tel quel, sans différence ou quelque chose comme ça.

Je pense que les performances ne sont pas un problème car il est peu probable que vous accédiez à des révisions plus anciennes.

Source

2009-04-15 08:51:59

J'ai fait la même chose, jusqu'à présent fonctionne bien pour moi. Le système est là depuis 2 ans maintenant. –

La manière la plus judicieuse de suivre les versions d'un document est souvent de suivre les modifications qui y ont été apportées. Ensuite, si une version particulière est demandée, elle peut être reconstruite à partir du document en cours et de l'ensemble partiel de modifications. Donc, si vous avez une bonne méthode pour décrire les types de changements à un document (cela dépendra en grande partie de ce que le document est et comment il est utilisé), alors utilisez une base de données pour suivre les changements et donc les versions .

Source

2009-04-15 08:54:50 CurtainDog

Le fait de stocker uniquement les différences entre les révisions présente l'avantage d'économiser de l'espace, mais ralentit le processus de récupération/reconstruction d'une révision spécifique et augmente également les risques de corruption des données (que se passe-t-il si une révision est perdue?). –

Oui, ce sont des points valides. L'approche optimale est quelque part entre et j'imagine que je serais assez sensible aux données de type je pense. Dans le cas de quelqu'un corrigeant l'orthographe d'un mot ou deux, il semble que vous ayez trop besoin de stocker le document entier. – CurtainDog

@Dario Je suis d'accord, et upvoted, votre réponse à cette question, mais je ne suis pas d'accord avec votre commentaire ici. La peur de «perdre» des données de votre base de données n'est pas un bon raisonnement et ralentir le processus de récupération d'une révision spécifique est moins problématique, comme vous le faites remarquer vous-même, car vous n'accéderez probablement pas aux anciennes versions. – Mocky

l'état actuel de l'art du disque dur, il n'a tout simplement pas la peine d'essayer d'optimiser les mécanismes de stockage texte: Document (ID, Name) et DocumentRevision (ID, DocumentID, Contents) tables feront le travail. le ID en DocumentRevision peut également servir de numéro de révision à l'échelle «référentiel». Si ce n'est pas le comportement que vous souhaitez, attribuez un VersionID distinct à chaque révision de document.

Source

2009-04-15 09:03:41

Conception de base de données pour les révisions de texte

Répondre

Questions connexes