Возьмем MySQL в качестве примера БД для выполнения этого (хотя на данном этапе я не ограничен реляционными вариантами) и синтаксис стиля Java для взаимодействия модели/БД.
Я хотел бы разрешить управление версиями отдельных значений столбцов (и соответствующих им типов) по мере того, как пользователи редактируют объекты. В первую очередь это делается для того, чтобы уменьшить объем памяти, необходимый для частого редактирования сложных объектов.
Простым примером может быть
- Food (Table)
- id (INT)
- name (VARCHAR(255))
- weight (DECIMAL)
Итак, мы можем вставить в базу данных объект, который выглядит как...
Food banana = new Food("Banana",0.3);
давая нам
+----+--------+--------+
| id | name | weight |
+----+--------+--------+
| 1 | Banana | 0.3 |
+----+--------+--------+
если мы затем хотим обновить вес, мы могли бы использовать
banana.weight = 0.4;
banana.save();
+----+--------+--------+
| id | name | weight |
+----+--------+--------+
| 1 | Banana | 0.4 |
+----+--------+--------+
Очевидно, что это приведет к перезаписи данных.
Я мог бы добавить в эту таблицу столбец ревизий, который можно было бы увеличивать по мере сохранения элементов, и установить составной ключ, объединяющий идентификатор/версию, но это все равно означало бы сохранение ВСЕХ атрибутов этого объекта для каждой отдельной ревизии.
- Food (Table)
- id (INT)
- name (VARCHAR(255))
- weight (DECIMAL)
- revision (INT)
+----+--------+--------+----------+
| id | name | weight | revision |
+----+--------+--------+----------+
| 1 | Banana | 0.3 | 1 |
| 1 | Banana | 0.4 | 2 |
+----+--------+--------+----------+
Но в этом случае мы собираемся хранить каждый отдельный фрагмент данных о каждом отдельном элементе. Это не очень эффективно, если пользователи вносят незначительные изменения в более крупные объекты, где текстовые поля или даже данные BLOB могут быть частью объекта.
Что бы мне действительно хотелось, так это возможность выборочного хранения данных дискретно, чтобы вес мог быть сохранен в отдельной БД сам по себе, который мог бы ссылаться на таблицу, строку и столбец, к которым он относится.
Затем это можно было бы разбить вместе с ПРОСМОТРОМ таблицы, который мог бы как бы наложить любые более поздние версии данных отдельных столбцов в микс для создания последней версии, но без необходимости хранить ВСЕ данные для каждой небольшой версии.
+----+--------+--------+
| id | name | weight |
+----+--------+--------+
| 1 | Banana | 0.3 |
+----+--------+--------+
+-----+------------+-------------+-----------+-----------+----------+
| ID | TABLE_NAME | COLUMN_NAME | OBJECT_ID | BLOB_DATA | REVISION |
+-----+------------+-------------+-----------+-----------+----------+
| 456 | Food | weight | 1 | 0.4 | 2 |
+-----+------------+-------------+-----------+-----------+----------+
Не уверен, насколько успешным может быть сохранение любых данных в виде большого двоичного объекта для последующего CAST обратно в исходный DTYPE, но подумал, что, поскольку я изобретал здесь функциональность, почему бы не сойти с ума.
Этот метод хранения также был бы довольно опасным, поскольку имена таблиц и столбцов могут быть полностью изменены, но, надеюсь, это, по крайней мере, описывает то поведение, о котором я думаю.
