Медленно меняющееся измерение или Slowly changing dimension (SCD)
Как-то давно мы уже обсуждали подходы по хранению исторических данных. Я решил, немного раскрыть тему.
Основа - статья в Wiki на ENG (больше инфы) и RUS.
Есть некоторое количество подходов к хранению исторических данных. Кратко перечислю.
Тип 0. Данные не меняются
Изменения не фиксируются, т.к. данные в строках/полях не изменяются.
Тип 1. Полная замена
Историчность не соблюдается, новые данные записываются вместо старых. Нет никакой возможности получить предыдущие значения.
💡Этот тип встречается постоянно. Вы его используете по умолчанию.
Тип 2. Вставка новой строки с новой версией данных
Помимо основных полей, в таблице появляются служебные поля, которые обслуживают историю.
Например, столбец “Actual” = {0 - не актуальная версия, 1 - актуальная}. С “1” может быть только одна строка для какого-то конкретного экземпляра сущности. С “0” может быть несколько.
Или две даты, обозначающие период действия строчки - from/to. Для актуальной, самой последней строки, значение в date_to заполняется либо null, либо какой-то заглушкой типа 01.01.4000.
Еще могут быть различные вариации с монотонно растущими версиями и т.п.
Чтобы получить актуальную запись достаточно отфильтровать по столбцам Actual = 1 или date_to = 01.01.4000 или взять максимальную версию.
💡Довольно часто, встречается при решении реальных задач, когда требуется проследить всю историю изменений сущностей.
Тип 3. Добавление доп полей для хранения старых значений
В основной строке мы создаем доп поля, в которых хранятся предыдущие значения.
Как только строка меняется, то в основные поля попадают новые значения, а в доп поля старые значения. Используется такой подход для ограниченного количества полей, только по тем, которые интересует история. Естественно, сохраняется всегда только текущая версия и предыдущая, мы не сможем проследить всю историю изменений.
💡Не прям, частый кейс, но если требуется хранение только текущего и предыдущего значения ограниченного набора полей - почему нет.
Тип 4. Добавление таблицы с историей
В основной таблице хранится самая актуальная информация.
В дополнительной таблице хранятся все изменения. Она повторяет по структуре основную + доп служебные поля (дата изменения, может быть пользователь кто менял и т.п.)
Как только меняется основная таблица, информация тут же помещается в историческую.
💡Довольно часто, этот тип используется в аудитах/логах и т.д.
+ еще три типа, являющиеся разными комбинациями и/или расширениями первых четырех.
У каждого типа есть свои плюсы и минусы и кейсы использования. Рекомендую посмотреть статью на Вики.
К чему это все?
Можно использовать один из подходов для решения вчерашней задачки 😉
#scd #архитектура
Канал Oracle Developer | Чатик 💬
Как-то давно мы уже обсуждали подходы по хранению исторических данных. Я решил, немного раскрыть тему.
Основа - статья в Wiki на ENG (больше инфы) и RUS.
Есть некоторое количество подходов к хранению исторических данных. Кратко перечислю.
Тип 0. Данные не меняются
Изменения не фиксируются, т.к. данные в строках/полях не изменяются.
Тип 1. Полная замена
Историчность не соблюдается, новые данные записываются вместо старых. Нет никакой возможности получить предыдущие значения.
💡Этот тип встречается постоянно. Вы его используете по умолчанию.
Тип 2. Вставка новой строки с новой версией данных
Помимо основных полей, в таблице появляются служебные поля, которые обслуживают историю.
Например, столбец “Actual” = {0 - не актуальная версия, 1 - актуальная}. С “1” может быть только одна строка для какого-то конкретного экземпляра сущности. С “0” может быть несколько.
Или две даты, обозначающие период действия строчки - from/to. Для актуальной, самой последней строки, значение в date_to заполняется либо null, либо какой-то заглушкой типа 01.01.4000.
Еще могут быть различные вариации с монотонно растущими версиями и т.п.
Чтобы получить актуальную запись достаточно отфильтровать по столбцам Actual = 1 или date_to = 01.01.4000 или взять максимальную версию.
💡Довольно часто, встречается при решении реальных задач, когда требуется проследить всю историю изменений сущностей.
Тип 3. Добавление доп полей для хранения старых значений
В основной строке мы создаем доп поля, в которых хранятся предыдущие значения.
Как только строка меняется, то в основные поля попадают новые значения, а в доп поля старые значения. Используется такой подход для ограниченного количества полей, только по тем, которые интересует история. Естественно, сохраняется всегда только текущая версия и предыдущая, мы не сможем проследить всю историю изменений.
💡Не прям, частый кейс, но если требуется хранение только текущего и предыдущего значения ограниченного набора полей - почему нет.
Тип 4. Добавление таблицы с историей
В основной таблице хранится самая актуальная информация.
В дополнительной таблице хранятся все изменения. Она повторяет по структуре основную + доп служебные поля (дата изменения, может быть пользователь кто менял и т.п.)
Как только меняется основная таблица, информация тут же помещается в историческую.
💡Довольно часто, этот тип используется в аудитах/логах и т.д.
+ еще три типа, являющиеся разными комбинациями и/или расширениями первых четырех.
У каждого типа есть свои плюсы и минусы и кейсы использования. Рекомендую посмотреть статью на Вики.
К чему это все?
Можно использовать один из подходов для решения вчерашней задачки 😉
#scd #архитектура
Канал Oracle Developer | Чатик 💬
👍14