Добър въпрос, аз също го проучвах.
Създавайте нова версия при всяка промяна
Попаднах на модула Versioning на драйвера Mongoid за Ruby. Самият аз не съм го използвал, но от това, което можах да намеря, добавя номер на версия към всеки документ. По-старите версии са вградени в самия документ. Основният недостатък е, че целият документ се дублира при всяка промяна , което ще доведе до съхраняване на много дублирано съдържание, когато работите с големи документи. Този подход обаче е добър, когато работите с документи с малък размер и/или не актуализирате документи много често.
Съхранявайте промените само в нова версия
Друг подход би бил да се съхраняват само променените полета в нова версия . След това можете да „изгладите“ своята история, за да реконструирате всяка версия на документа. Това обаче е доста сложно, тъй като трябва да проследявате промените във вашия модел и да съхранявате актуализации и изтривания по начин, по който приложението ви може да реконструира актуалния документ. Това може да е трудно, тъй като имате работа със структурирани документи, а не с плоски SQL таблици.
Съхраняване на промените в документа
Всяко поле може да има и индивидуална история. Възстановяването на документи до дадена версия е много по-лесно по този начин. Във вашето приложение не е нужно изрично да проследявате промените, а просто да създадете нова версия на свойството, когато промените стойността му. Един документ може да изглежда така:
{
_id: "4c6b9456f61f000000007ba6"
title: [
{ version: 1, value: "Hello world" },
{ version: 6, value: "Foo" }
],
body: [
{ version: 1, value: "Is this thing on?" },
{ version: 2, value: "What should I write?" },
{ version: 6, value: "This is the new body" }
],
tags: [
{ version: 1, value: [ "test", "trivial" ] },
{ version: 6, value: [ "foo", "test" ] }
],
comments: [
{
author: "joe", // Unversioned field
body: [
{ version: 3, value: "Something cool" }
]
},
{
author: "xxx",
body: [
{ version: 4, value: "Spam" },
{ version: 5, deleted: true }
]
},
{
author: "jim",
body: [
{ version: 7, value: "Not bad" },
{ version: 8, value: "Not bad at all" }
]
}
]
}
Маркирането на част от документа като изтрита във версия все още е малко неудобно. Можете да въведете state поле за части, които могат да бъдат изтрити/възстановени от вашето приложение:
{
author: "xxx",
body: [
{ version: 4, value: "Spam" }
],
state: [
{ version: 4, deleted: false },
{ version: 5, deleted: true }
]
}
С всеки от тези подходи можете да съхранявате актуална и изравнена версия в една колекция и данните за историята в отделна колекция. Това трябва да подобри времето за заявка, ако се интересувате само от най-новата версия на документ. Но когато имате нужда както от най-новата версия, така и от исторически данни, ще трябва да изпълните две заявки, а не една. Така че изборът за използване на една колекция срещу две отделни колекции трябва да зависи от колко често приложението ви се нуждае от исторически версии .
По-голямата част от този отговор е просто изхвърляне на мислите ми, всъщност все още не съм опитвал нищо от това. Поглеждайки назад към него, първият вариант е може би най-лесното и най-доброто решение, освен ако режийните разходи за дублирани данни не са много важни за вашето приложение. Вторият вариант е доста сложен и вероятно не си струва усилията. Третият вариант е основно оптимизация на вариант две и би трябвало да е по-лесен за изпълнение, но вероятно не си струва усилията за внедряване, освен ако наистина не можете да преминете към вариант едно.
Очакваме с нетърпение обратна връзка за това и решенията на други хора на проблема :)
