Я всё держу в реляционной базе данных, несколько основных таблиц: Фильмы, Издания, Форматы и Релизы. В таблице "Фильмы" – каноническое название, режиссёр и уникальный идентификатор фильма. "Издания" связаны с фильмом и содержат дату релиза, регион, язык и особые возможности. "Форматы" (Blu-ray, DVD, 4K и т.д.) указывают на издание и содержат информацию о кодеке, типе HDR и о том, дисковый это вариант или стриминговый. В таблице "Релизы" – дистрибьютор, номер каталога и физическое местонахождение в хранилище. Обычно узкое место проявляется в таблице "Релизы", когда приходится отслеживать каждую мелочь – пресс-киты и изменения дистрибьюторов. Данные начинают превращаться в кашу, если не нормализовать каждый новый код дистрибьютора или если релизу внезапно меняют название в процессе. Моя схема работает до тех пор, пока количество правок за год не взрывается – тогда я начинаю писать скрипты для автоматического слияния или для отметки аномалий. Если у тебя возникают похожие проблемы, главное – строгий UUID для каждой сущности и небольшая таблица аудита, в которой регистрируются все изменения, чтобы я мог откатить неудачный импорт, не теряя всю проделанную работу.

Вот, думаю, ты прав насчёт аудита в одну строку; я так делал с маленькой таблицей `change_log`, но заметил, что она забивается, когда заливаю целиком каталог дистрибьютора. Добавить колонку версии к Editions и Formats – отличный ход, чтобы фиксировать состояние каждого Release – никаких больше "призрачных" ссылок. Я настрою партиционированный аудит, как ты и предложил, на квартальной основе; если дистрибьютор в марте выкинет сюрприз-издание, смогу откатить конкретный снимок за секунды, а не копаться в миллионе строк. Спасибо за совет – в следующий раз пришлю тебе пример схемы.