Нужно ли хранить две версии документа — минимальную и максимальную
Что проверяют
Умеете ли вы вывести требование из сценария, а не проектировать хранилище на всякий случай. Вопрос с виду про объём, на деле про то, зачем нужны прошлые состояния: показать различия, откатить правку, доказать, каким документ был в нужный момент.
Как отвечать
Сначала уточнить назначение. Если нужны только текущая версия и исходная, двух записей достаточно. Если требуется аудит или откат на любой шаг, двух мало: нужна полная история, а это другая схема и другая стоимость.
Схема обычно такая: отдельная таблица версий с полями document_id, version, created_at, author_id и признаком актуальной записи. Уникальный индекс по паре document_id, version не даёт появиться двум одинаковым номерам, а частичный уникальный индекс по признаку актуальности не даёт появиться двум текущим. В Java ту же задачу закрывает Hibernate Envers: он ведёт теневые таблицы ревизий сам, если история нужна ради аудита, а не как часть доменной логики.
Отдельно стоит сказать про формат хранения. Полные снимки читаются одним запросом, дельты экономят место, но требуют проигрывать цепочку. Разумный компромисс это снимок текущей версии целиком плюс дельты для прошлых.
Где спотыкаются
Путают версионирование документа с @Version из JPA. Поле @Version служит оптимистической блокировке, оно защищает от затирания параллельной правкой и хранит счётчик текущей строки. Прошлых состояний в нём нет.
Выбирают дельты ради экономии места и получают дорогое чтение: чтобы показать документ, приходится собирать его из цепочки изменений, а одна испорченная запись делает недоступным всё, что было после неё.
Не проговаривают конкурентную запись. Без уникального индекса два пользователя, сохранившие правку одновременно, спокойно создадут две версии с одним номером, и «максимальная» перестанет быть однозначной.