Рекомендуемая структура типа сообщений для сайта TV Schedule?

Я работаю над перестройкой сайта для телевизионной сети с довольно большим количеством контента (~ 50 шоу, ~ 3000 эпизодов, ~ 300 фильмов, текущие записи в графике и т. Д.).

Мы хотим иметь возможность перечислить график предстоящего программирования таким образом, который очень похож на ABC: http://abc.go.com/schedule

Их существующая схема структурирования и подключения пользовательских типов сообщений и таксономий является результатом нескольких разных разработчиков за несколько лет, и она стала довольно запутанной, поэтому мы начинаем с нового сайта, и мы хотим делать что-то чисто.

Мы используем плагин Toolset (в частности, «Типы и виды») для настройки модели контента для сайта: https://wp-types.com

Вот что мы имеем до сих пор, что я чувствую себя достаточно уверенно:

  • Основными типами контента являются фильмы, шоу и эпизоды. В настоящее время они настроены как пользовательские типы сообщений.

  • На шоу и в кино есть таксономии для таких вещей, как жанр, независимо от того, является ли контент оригинальным или приобретенным, и так далее.

  • Шоу и эпизоды имеют отношения «один ко многим», причем многие эпизоды принадлежат к одному Шоу. Фильмы – это автономные записи контента.

  • В каждом шоу, эпизоде ​​и фильме есть название, описание и множество метаданных, которые импортируются из файла CSV (например, номер эпизода, код заголовка, дата первого эфира и т. Д.).

Большой вопрос заключается в том, как обрабатывать часть Schedule на сайте.

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

Каждый день записи за два недели (с шагом в полчаса) будут импортироваться через CSV-файл на хроном задании, удаляя все старые записи расписания и добавляя новые в процесс. Итак, мы берем сотни и сотни записей.

Эти записи в графике будут иметь имена типа «02-27-2017 – 7: 00-8: 00», и их содержание и метаданные будут по существу дублированием содержимого, которое уже было в эпизоде ​​«Эпизод» или «Фильм».

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

Будет ли такое расписание, как одно на ABC, требовать, чтобы эти элементы расписания являлись их собственными индивидуальными записями типа записей, или есть более чистый способ справиться с этим?

Если они действительно должны быть персонализированными типами записей, как мы можем сохранить их как можно более чистыми и минимальными, ссылаясь только на контент, который уже существует в соответствующих эпизодах или фильмах, а не дублирует его?

Любое понимание очень ценится!

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

Для этого я бы использовал пользовательские таблицы: один для временных интервалов, один для сообщений.

table slots id | start (DATETIME) | end (DATETIME) table slot_relations id | slot_id (INT) | post_id (INT) 

Вам не требуется описание времени, но вам могут потребоваться перекрывающиеся временные интервалы, и вам понадобятся очень быстрые запросы. Установка столбцов слотов как DATETIME (в отличие от VARCHAR метаданных) поможет вам выполнять пользовательские запросы и сравнения.

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