Универсальная стратегия управления версиями избранных данных таблицы в в большой степени нормализованной базе данных
У меня есть поддельный сервис, который возвращает простую функцию ... рабочая демоверсия здесь ... вы можете использовать значение, как только сервис вернет вызов
constructor(private uService: UploadService) {
this.uploadMarketingAgreement('');
}
uploadFiles(event, type) {
return new Promise((resolve, reject) => {
this.uService.upload(this.formData).subscribe(
response => { console.log("data from service:" + response); resolve(response); }
, errr => { console.log("error from service:" + errr); reject(errr); }
);
});
}
async uploadMarketingAgreement(event) {
const uploadFilesVal = await this.uploadFiles(event, "profilepic");
console.log('from await:' + uploadFilesVal);
//how to get result of the above method in a varaible
}
2 ответа
Некоторые быстрые идеи:
Полная копия: Создайте копию структуры, но для каждой таблицы добавляют a version_id столбец к PK и всему FKs; таким образом можно создать копии жизненных данных с полной ссылочной целостностью.
- про: легкий запросить историю
- довод "против": большая сумма (избыточные скопированные данные)
Копия изменения: Только скопируйте материал, который на самом деле изменяется, наряду с valid_from / valid_to данные.
- про: низкий объем данных скопирован
- довод "против": трудно для запросов, потому что нужно присоединиться на интервалах
Изменение: Это относится к обеим схемам. Вместо того, чтобы создать копию структуры, Вы могли бы keept текущая запись в той же таблице как старые версии, но отмечать его как текущий.
- про: меньшее число таблиц, более легкое смешивание истории и текущей информации
- довод "против": нормальное функционирование воздействует на намного большие таблицы, которые вызовут влияние производительности
Аудит журнала: В зависимости от Ваших фактических требований это быть достаточным просто создать журнал аудита как это:
id, timestamp, changed_table, changed_column, old_value, new_value, changed_by
Вы могли бы расширить это до полной структуры таблицы:
transaction, table_change, changed_column
- про: универсальный, следовательно легкий реализовать для большого количества таблиц
- довод "против": если необходимо восстановить состояние ряда записей в установленный срок, запросы станут кошмаром
Я записал блог о различных подходах к управлению версиями, но быть предупрежденным: это находится на немецком языке.
У людей организации хранилищ данных есть несколько алгоритмов для "медленно изменяющихся размеров".
Более сложные алгоритмы обеспечивают диапазоны данных вокруг значения размера для указания, когда это допустимо.
В зависимости от Ваших требований управления версиями Вы могли сделать одну из этих вещей, запертых от Kimball Инструментарий Организации хранилищ данных.
Присвойте номер версии строкам таблицы структуры. Это означает, что необходимо сделать некоторое обоснование для сбора полной структуры. Это включает число выбранной версии unioned со строками, которые неизменны в более ранней версии.
Присвойте диапазон дат или диапазон версии к строкам таблицы структуры. Это означает, что некоторые строки имеют даты начала и даты окончания; некоторые строки будут иметь даты окончания в некоторую эпоху в невозможном будущем. Или при использовании номеров версий у Вас будут пара начинать-конца или пара начинать-бесконечности, которая указывает, что эта строка является все еще текущей. Можно затем тривиально запросить строки, которые допустимы "сегодня" или относятся к запрашиваемой версии.
Клонируйте структуру для каждой версии. Это неприятное, потому что операция клонирования является дорогостоящей. Запросы однако, тривиальны, потому что вся структура доступна с единственным, последовательным номером версии.