Хранение ревизий реляционных объектов эффективным способом

Question

Я не уверен, что на этот тип вопросов уже был дан ответ. В моей базе данных есть таблица продуктов и таблица спецификаций. Каждый продукт может иметь несколько спецификаций. Здесь мне нужно сохранить ревизии каждого продукта в базе данных, чтобы впоследствии запросить их для целей истории.

Поэтому мне нужен эффективный способ хранения отношений продуктов со спецификациями каждый раз, когда пользователи вносят изменения в эти отношения. Также объем данных может стать очень большим. Например, предположим, что в базе данных содержится 100000 продуктов: каждый продукт может иметь 30 спецификаций, а также минимум 20 ревизий для каждого продукта. Таким образом, благодаря хранению всех данных в одной таблице количество данных становится чрезвычайно большим.

Есть предложения?

Answer 1

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

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

Вы можете создать составной первичный ключ для таблицы продуктов, например, PRIMARY KEY (product_id, revision). Возможно, будет полезен сохраненный процесс для поиска текущей ревизии - путем выбора строки с наибольшим значением revision для определенного product_id -.

Answer 2

Я бы порекомендовал иметь таблицу, точную копию текущей таблицы со столбцом HistoryDate и хранить ревизии в этой таблице. Это вы можете сделать для всех 3 рассматриваемых таблиц.

Сохраняя ревизию отдельно от основных таблиц, вы не понесете никаких потерь производительности при запросе к основным таблицам.

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