arangodb: история значений атрибутов

Question

Для определенных узлов в нашей базе данных нам нужно хранить историю каждого измененного значения поля.

Мы рассматриваем две возможные структуры для этого:

1. Использование индекса значения ключа с записями в форме

   id.attribute_name.counter = {
       "field": "name",
       "old_value": "jon",
       "new_value": "john",
       "datetime_modified": "some-date",
       "modified_by": "some-user"
   }
   

   где id является уникальным идентификатором записи, и counter просто увеличенное целое число.

2. Использование структуры графа и наличие "дельта" узлов, соединенных с основным узлом, с ребром "модификации" и тем же объектом JSON (+ имя атрибута), хранящимся в этом узле.

Информация истории иногда будет использоваться, чтобы решить, следует ли обновить запись новой информацией.

Хотелось бы узнать плюсы / минусы обоих подходов.

Answer 1

Я думаю, что есть третий подход, который вы могли бы использовать:

3. Создайте коллекцию обновлений, имея документы следующего формата:

   {
       reference: <_id of updated object>,
       attribute: <name of the updated attribute>,
       counter: <number>,
       old_value: ...,
       new_value: ...,
       date_modified: ...,
       modified_by: ...
   }
   

   с объединенным хеш-индексом по ссылке и атрибуту.

Это может содержать всю необходимую вам обновленную информацию.

Почему я предпочитаю этот метод:

• Имеет недостаток, что вы должны поддерживать счетчик обновлений для каждого атрибута где-то, так как нет _id запрос префикса (пока) в AQL. Это потребуется для получения всех обновлений для одного атрибута в документе.

• Структура графа делает то же самое, что и мой третий подход, однако создает ненужные накладные расходы, создавая два индекса, которые вам на самом деле не нужны (_from а также _to), вам понадобится только один из них.

• Преимущество выше 1. в том, что вы можете сортировать счетчики и легко получать последние 5 обновлений. Кроме того, вам не нужно вести счетчик где-то еще или использовать "проб и ошибок", чтобы найти последнее обновление. Выше 2. он имеет преимущество в том, что он использует комбинированный индекс вместо краевого индекса, где одна из краевых сторон не используется.

Пример AQL (предположим, что ваши записи хранятся в коллекции records:

FOR r IN records
    FILTER r.name == "super important"
    FOR update IN updates
        FILTER update.reference == r._id && update.attribute == "name"
        SORT update.counter DESC
        LIMIT 5
        RETURN update