Version de CouchDB et document

12

Je travaille actuellement sur une application wiki-esque utilisant CouchDB et j'essaie d'implémenter un schéma de version de document. Pour moi, il y a deux façons de procéder:

Stockez chaque version dans un document distinct
Stockez les anciennes versions sous forme de pièces jointes à un seul document.

En ce moment, j'ai une forme de travail n ° 1. Lorsqu'un utilisateur modifie un document et l'enregistre, le serveur principal copie d'abord la révision précédente dans un nouveau document, puis enregistre la nouvelle version. Chaque document possède un tableau «historique» qui contient des données sur chaque version (le document _id de l'ancienne version, un horodatage, l'éditeur, etc.).

Étant donné que ce tableau d'historique peut devenir assez long pour un document fréquemment mis à jour, j'ai une vue qui récupère un document sans historique lors d'une lecture normale (et une autre vue pour récupérer l'historique).

Ma question est la suivante: je me sens mal à l'aise avec mon approche actuelle et j'ai pensé à passer à la méthode de l'attachement. Mais je ne suis pas sur. J'espère que quelqu'un qui connaît mieux CouchDB que moi (je n'y suis que depuis quelques semaines - et c'est mon premier projet utilisant CouchDB ... et NoSQL) peut me dire quels sont les avantages et les inconvénients de chacun approche. Ou existe-t-il peut-être un autre schéma de version que j'écarte?

database-design couchdb

— James Adam
source

2

Bien que je ne puisse pas du tout parler de l'impact sur les performances, le système que vous utilisez est "spirituellement" conforme à CouchDB. Le stockage des versions précédentes en tant que hiérarchie de réponses est idiomatique, comme c'est le cas dans "l'ancêtre spirituel" de CouchDB, la base de données de documents Lotus Notes (NSF) (Damien Katz a travaillé en profondeur sur l'une avant de développer l'autre, en gardant et en améliorant le meilleur) tout en jetant les exigences de compatibilité en arrière et en arrière / bugward, de nombreuses questions structurelles plus basiques trouveront des réponses dans les notes.)

2

Le stockage des modifications uniquement sera une bonne idée, car le stockage de documents plus anciens en tant que documents séparés ou pièces jointes à la révision finale de la base de données créera une surcharge pour le serveur de base de données.

Chaque fois que vous modifiez une valeur de clé dans votre document, ajoutez une nouvelle clé nommée _h_i_s_<key_name>. Dans la nouvelle création (ou créée lors de la dernière mise à jour), ajoutez des objets comme ci-dessous après chaque modification / mise à jour: -

{
key_name: "Hello",
_h_i_s_key_name:{time_of_update:value_of_key_name_before_update},
....
}

ou

    {
    key_name: "Hello",
    _h_i_s_key_name:[{time:time_of_update,value:value_of_key_name_before_update}, {time:time_of_last_update,value:value_of_key_name_before_last_update}],
    ....
    }

Cette approche permettra d'économiser beaucoup d'espace disque et de bande passante de réplication à long terme.

— Ravinder Payal
source

0

Sans aucune connaissance de CouchDB. Cependant, le stockage de chaque version ne diffère que marginalement de son prédécesseur est un gaspillage de stockage. Je recommande de stocker uniquement les modifications.

Vous voudrez peut-être jeter un œil ici ou rechercher le versionnage des données.

— xuma202
source

Cette réponse ne dit pas laquelle de l'option 1 (documents séparés) ou 2 (dans le cadre du document) est la meilleure.

— binki

0

des années plus tard ;-)

vous n'avez pas à enregistrer les modifications car CouchDB le fera pour vous. Si un document est modifié, une nouvelle révision sera créée. Sachez qu'il s'agit physiquement d'un autre document avec le même _idmais un nouveau _rev(révision) et qu'il consommera de l'espace sur votre disque.

Pour sûr, vous devrez conserver toutes les révisions, ce qui signifierait que vous avez besoin d'un très grand disque.

— awenkhh
source