PgSQL, Django - история для таблицы со многими полями - как правильно организовать?

Question

Я новичок в Django и не очень разбираюсь в PgSQL. Мне нужно создать таблицу с около 10 полей. Дело в том, что каждый элемент у меня постоянно меняется и мне нужно вести историю изменений для каждого поля. На данный момент я нашел несколько решений для этой цели, но я обеспокоен:

1) https://github.com/arkhipov/temporal_tables

Реле на БД и триггеры. Проблема заключается в том, что история хранится в дополнительной отдельной таблице, поэтому при каждом изменении 1 поля будет создаваться новая запись истории с 9 избыточными полями, и я намерен показывать историю по полю, а не по элементу, поэтому объем данных вырастет в 9 раз быстрее без цели. Или БД это оптимизирует? Кроме того, есть изображения, которые, естественно, имеют только историю включения / выключения даты и времени.

2) https://github.com/treyhunner/django-simple-history

Лучше, чем первый, потому что имеет интеграцию с Django. Также есть много функций, таких как Custom history_date (у меня есть много снимков уже в файлах). Но все та же проблема, что и 1

3) Вручную создайте основную таблицу с идентификатором и создайте таблицы отношений для каждого из полей. Похоже, кошмар для управления. Кроме того, для получения полной полной записи необходимо выполнить много соединений (Может ли Django работать с VIEW?)

Так что вы можете посоветовать лучшее решение? Или, может быть, мои мысли о большом количестве лишних данных неверны, и я должен перестать беспокоиться?

Answer 1

Обычно PG очень хорошо оптимизирует производительность.

Это действительно зависит от того, сколько данных вы будете хранить. Однако нельзя ли создать дополнительную таблицу для каждого изменения, которое вы делаете для строки , а не для поля ? Как это повлияет на это?

Но вы также можете работать с постоянством истории. Например, хранить только последние 3 версии каждого поля. Это сведет к минимуму ваши данные, но вам нужно управлять ими по коду или создать триггер / процедуру. В дополнение к этому вы всегда можете сделать резервную копию и сохранить ее локально / в облаке, если хотите когда-нибудь ее восстановить.

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