Идентификаторы видео, статей и плейлистов

Один материал может иметь статью, полное видео, короткую демонстрацию и место в плейлисте. Если считать все URL одной публикацией, сравнение потеряет смысл. В этом уроке построим реестр устойчивых объектов и их представлений.

У ProfessorWeb Lab есть темы сохранения URL и подготовки Markdown. Внешние адреса демонстрационные и не обозначают существующих роликов. Мы не создаём видео и не проверяем чужие публикации.

Тема, материал и представление

Введём три уровня. topic_id связывает общую учебную задачу, content_id обозначает самостоятельный материал, representation_id — конкретное представление на площадке. У темы preserve-url есть статья A01, полный ролик V01 и короткий S01. Они связаны смыслом, но имеют разные обещания: статья даёт таблицу, полное видео показывает процесс, короткое демонстрирует один ошибочный случай.

В content-registry.csv храним platform, format, public_url, native_id и published_state. Для наших строк последнее значение равно demonstration. Такой признак нельзя потерять при экспорте: иначе вымышленная ссылка начнёт выглядеть как готовая публикация. У внешнего идентификатора тоже явно обозначено лабораторное происхождение.

Плейлист получает отдельный объект PL01. Поисковые показатели страницы плейлиста не равны сумме роликов внутри него. Google прямо поясняет это различие для фильтра страниц. Если мы увидим рост поисковых кликов PL01, можно изучить название и описание плейлиста, но нельзя приписать этот рост V01 без данных о самом ролике.

Адрес проигрывателя, страница просмотра и файл видео являются разными URL. В нашей карте есть watch_page_url, embed_url и необязательный media_file_url. У встроенного стороннего ролика редактор может не иметь собственного стабильного адреса байтов. Не нужно выдумывать его по шаблону или подменять страницей просмотра. Для аналитики страницы важен наблюдаемый URL, для технических метаданных — правильный вид адреса.

Рассмотрим изменение названия ролика. content_id остаётся V01, меняется title_version. Если вместо этого ключом было название, прошлый и новый экспорт перестали бы соединяться. Устойчивый внутренний ключ сохраняет историю без требования никогда не редактировать заголовок. Аналогично, имя Markdown-файла статьи может измениться без изменения её permalink.

Соединение с таблицей поиска

В поисковой выгрузке есть URL, но нет наших content_id. Для нормализации используем таблицу представлений. Сначала сохраняем исходный адрес, затем ищем соответствие, а уже потом добавляем внутренний ключ. Неизвестный URL получает unmapped, а не ближайший похожий материал. Иначе ошибка сопоставления будет выглядеть как неожиданная динамика правильного ролика.

Некоторые параметры URL меняют лишь контекст, другие обозначают сам объект. У YouTube параметр v выбирает видео, list указывает плейлист. Нельзя удалить все параметры универсальным правилом и получить верный ключ. В лабораторном договоре разобраны отдельные формы адресов, а исходная строка остаётся для пересмотра. Если правило неизвестно, связь откладывается.

Для короткого и полного видео создадим отдельные content_id, даже если оба относятся к одной теме. Это позволяет сравнивать форматы, не смешивая счётчики. При этом редакционная таблица сможет сгруппировать их по topic_id. Такой двойной взгляд полезен: один отвечает за объект публикации, другой — за покрытие учебной задачи.

Результат — реестр, который различает шесть материалов, их представления и отдельный плейлист. Названия можно обновлять, а прошлые строки сохранят связь. Следующий урок добавит договор выгрузки, чтобы устойчивые ключи не скрывали различие дат, фильтров и единиц.

Добавьте случай недоступной публикации. Если ролик снят с просмотра, реестр не должен стирать его историю. Ставим соответствующее состояние и дату, сохраняем прежний идентификатор, а текущий маршрут получает задачу на замену ссылки. Исторические показатели остаются объяснимыми, хотя материал больше не доступен читателю.

Не пытайтесь определять формат только по длительности. Короткий фрагмент может быть опубликован как обычное видео, а URL поверхности сообщает другое представление. В нашей модели формат назначается при редакционной подготовке и сопоставляется с фактической формой публикации. Это позволяет говорить о самостоятельном учебном фрагменте, а не о произвольном пороге минут.

В реестр стоит добавить отношения материалов, но не превращать их в тождество. A01 и V01 могут быть complementary, S01 — diagnostic_variant, PL01 — collection. Если видео обновилось, связь со статьёй проверяется содержательно, а не автоматически по общей теме. Некоторые главы могут сохранять совместимость, другие потребуют новой демонстрации. Такие частичные отношения легче сопровождать, чем утверждение, что статья и ролик всегда полностью совпадают. Это позволяет обновлять библиотеку постепенно, сохраняя полезные фрагменты и объясняя читателю, где находятся современные данные и полный пример.

Реестр может содержать и вариант локализованной публикации. У него отдельный representation_id и язык, тогда как общий материал либо тема сохраняют связь. Однако перевод может иметь собственные примеры и обещание. Если результат существенно изменился, требуется новый content_id. Такое решение принимается по содержанию, а не только по одинаковым буквам внешнего native_id, и фиксируется в истории карты.

Чтение сохранённого состояния

Откройте реестр и сравните V01, S01, A01 и PL01. У первых трёх общая тема, но разные самостоятельные результаты и адреса. Плейлист имеет другую роль: он организует маршрут. Поэтому группировка по теме может включать несколько объектов, а сравнение публикаций обязано сохранять их отдельные ключи.

Ключ	Назначение устойчивого имени
topic_id	Связывает учебную задачу, даже если она представлена статьёй, длинной демонстрацией и отдельной диагностикой.
content_id	Обозначает материал независимо от редактируемого названия, площадки размещения и версии его описания.
representation_id	Позволяет сопоставить конкретный публичный URL с объектом, сохранив исходную наблюдаемую форму адреса.
native_id	Хранит исходное имя площадки отдельно; лабораторные значения вымышлены и не обозначают настоящие ролики.

В нашем наборе даже внешние формы URL используют домен .example. Они нужны для объяснения структуры, а не для открытия видео. Это предотвращает случайное связывание выдуманных чисел с существующими публикациями. Адаптируя модель, нужно заполнять реестр только проверенными собственными объектами.

Добавьте в своей копии новую версию заголовка V01, сохранив ID. Затем создайте отдельный ролик о другом результате. Для него требуется новый content_id, даже если в названии остались прежние слова. Так реестр отличает редакционное уточнение существующей публикации от создания нового материала.

Основной артефакт content-registry.csv находится в lesson-03 архива серии. Полный снимок содержит также исходные таблицы и договоры. Они читаются вручную; результаты примеров описаны как ожидаемые, выполнение не проводилось.

Первичные источники: video guide, video seo.