Дизайн таблицы истории SQL для иерархических данных

Question

У меня есть некоторые данные об элементах, которые включают несколько подпунктов из разных таблиц, связанных с внешними ключами.Чтобы показать клиентам историю товара со всеми связанными подпунктами, мне нужно сохранить изменение данных в базе данных, и появятся несколько вариантов.

1. Создать таблицу _histс триггерами всех таблиц для хранения данных всякий раз, когда происходит изменение в любой из таблиц.Все изменения сохраняются, но было бы трудно получить данные элементов из всех таблиц, поскольку между таблицами _hist нет связи

2. Создать единую таблицу истории со всеми столбцами извсе таблицы.Поскольку существует иерархия элементов, невозможно сохранить изменения только с одной строкой.

Поскольку ни одно из вышеперечисленных действий не работает, как ожидалось, в результате таблица истории быласоздается со столбцами Id, timestamp и т. д. и дополнительным столбцом для хранения изменений.

При каждом изменении мы извлекаем все таблицы, преобразуем данные в формат JSON и сохраняем их в таблице истории.Преобразованные данные JSON аналогичны приведенным ниже.

{
    "ItemId": 1,
    "ItemStatus": 100,
    "SubItmems": [
        {
            "SubItemId": 1,
            "ItemId": 1,
            "SubItemStatus": 200,
            "SubChildItems": [
                {
                    "SubChildItem": 1,
                    "SubItemId": 1,
                    "SubChildItemStatus": 300,
                },
                {
                    "SubChildItem": 2,
                    "SubItemId": 1,
                    "SubChildItemStatus": 400,
                },
            ],
        }
    ],
    "ItemTags": [
        {
            "TagId": 1,
            "TagStatus": "OK",
        },
    ],
}

Однако на получение и преобразование требуется время, и у нас возникают некоторые проблемы с производительностью.

Мне нужно улучшить текущуюструктура, но не нашли эффективную.

Пожалуйста, поделитесь идеями, если у вас есть.

Спасибо!

Answer 1

Некоторые идеи (не знаю, если применимо, но делятся):

• Таблица истории, содержащая только идентификатор клиента, дату и сериализованный JSON в BLOB-объекте.Триггер может вызвать SP, который будет выполнять эту работу. (Рекомендуемое решение)

• Таблица истории с TableName, DateTime, ID, Field, OldValue, NewValue.Таким же образом, триггер, который добавляет записи.

Если вы хотите иметь чистую надежную историю, вам придется играть с триггером.Все зависит от того, как вам нужно использовать эту историю (просто читая или потребляя ее).