Рекомендуемый способ хранения информации истории аудита для очень большой таблицы

107
13

Для нового проекта мы используем Spring, Java 8 и SQL Server 2012, у нас, вероятно, будет очень большая (в смысле широкий, около 150 столбцов) таблица, чтобы хранить информацию о контракте. Одной из целей проекта будет сохранение некоторой информации аудита относительно информации о контракте. Эта историческая информация также должна быть доступна в самой заявке, поэтому можно просмотреть более старые версии контракта.

Если бы это была меньшая таблица (и резка таблицы на более мелкие части - это то, что можно определенно рассмотреть), я бы просто сделал новую запись в таблице для контракта или, возможно, имел отдельную таблицу для исторической информации.

Однако это не кажется оптимальным, когда дело доходит до использования диска. Несмотря на относительно небольшое количество контрактов, у нас будет (<100 тыс.), Количество истории, возможно, будет расти в будущем, в зависимости от того, как работают люди.

Я знаю, что альтернативой может быть просто хранить вещи в ключевом/ценностном подходе, чтобы поддерживать разные дельта, но как-то кажется болью, чтобы восстановить контракт в каком-то случае, например, для того, чтобы показать историческую информацию.

Не хватает ли хороших альтернатив?

спросил(а) 2017-04-06T10:01:00+03:00 3 года, 5 месяцев назад
1
Решение
57

Таблица SQL Server Temporal - это примитивный дизайн, который скроет много системных усилий, которые могут представлять неразрешимые проблемы с производительностью. Все это и только представляет собой моно-временный доступ (время транзакции) к данным. Ответ на аналогичный вопрос здесь обсуждается в версии Normal Form. В этом конкретном ответе я также представил только дизайн времени транзакции, но есть ссылки на дальнейшие детали конструкции, которые представляют небольшую модификацию, чтобы довести ее до полного двухвременного доступа (действительное/эффективное время, а также время транзакции),

Вкратце, эффективное время - это когда данные вступили в силу, а не когда данные были записаны в базу данных. Например, цена изменилась с 14 до 32 долларов США по состоянию на 1 января. Однако база данных не обновлялась до 7 января. Если вы получите доступ к данным с использованием времени транзакции по цене с 3 января, вы получите 14 долларов США, старая цена. Об этом сообщила бы база данных, если бы вы выполнили запрос в эту дату. Но если вы получите доступ к эффективному времени, вы вернетесь к 32 долларам США, потому что это была цена, которая действовала в то время, даже несмотря на то, что база данных не была осведомлена об этом до следующего. Существуют требования для обоих типов доступа.

Одно из преимуществ моего метода (кроме полного двухвременного доступа) заключается в том, что вы определяете, какие поля контрактной организации соответствуют "версии" (отслеживать все изменения). Кроме того, поскольку вы контролируете все аспекты дизайна, вы можете лучше справляться с проблемами, связанными с производительностью, если они появятся. Не говоря уже о том, что вам не нужно изучать новую форму SQL.

Хорошо, есть больше преимуществ:

    Текущие и исторические данные находятся в одних и тех же таблицах. Вам не нужно заранее определять, являются ли данные текущими или историческими для определения источника данных. Фактически, тот же запрос используется для извлечения текущих данных, данных времени транзакции или данных эффективного времени. Из-за отсутствия зависимости Row Spanning производительность впечатляет.

ответил(а) 2017-04-07T09:38:00+03:00 3 года, 5 месяцев назад
41

Если вы используете SQL Server 2016, вы можете использовать временную таблицу. Это позволит вам запрашивать данные как в любой момент времени.

ответил(а) 2017-04-06T10:19:00+03:00 3 года, 5 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема