Как структурировать таблицы для телевизионного слежения? - PullRequest
Новая
       72

Как структурировать таблицы для телевизионного слежения?

0 голосов
/ 04 мая 2020

Я работаю над приложением, которое отслеживает, какие телешоу вы смотрите и какие эпизоды из этого шоу вы смотрели.

В настоящее время я могу отслеживать, какие пользователи смотрят какие шоу, это относительно просто и он структурирован так:

структура таблицы

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

После этого у меня есть другая таблица TV_SHOWS, в которой user_id в качестве внешнего ключа хранится некоторая информация о шоу и, что особенно важно, поле с именем user_watching, которое дает логическое значение значение, определяющее, смотрит ли пользователь это шоу.

Как это работает: когда пользователь нажимает кнопку, чтобы добавить шоу, в таблицу TV_SHOWS вставляется строка со всей информацией и user_watching = true в какой-то момент пользователь может sh прекратить просмотр, чтобы он мог щелкнуть другую кнопку, которая просто обновит user_watching = false.

Теперь я sh на ex pand на этой идее, чтобы пользователи могли отслеживать, какие сезоны и эпизоды телешоу они смотрели, телешоу состоит из множества сезонов, а каждый сезон в большинстве случаев состоит из множества эпизодов.

Я бы хотел несколько помогите с тем, как лучше всего структурировать эту схему базы данных.

Сначала я подумал, что могу просто расширить, например, по тем же направлениям, что и раньше:

Я просто добавляю два идентификатора для сезона и эпизода Таким образом, я могу определить, смотрел ли пользователь сезон, посмотрев, смотрели ли они все эпизоды в этом сезоне, и смотрели ли они шоу, проверив, смотрели ли они все сезоны в шоу, но я не Думаю, это хорошая практика.

Я мог бы попробовать составить одну таблицу для шоу, другую для сезонов и финал для эпизодов, но я не уверен, где бы я «отслеживал», если бы пользователь смотрел один из них, должен ли он быть в этой таблице c или мне понадобится другая таблица для его отслеживания?

Ответы [ 2 ]

0 голосов
/ 05 мая 2020 
-- User USR exists.
--
user {USR}
  PK {USR}

-- TV show SHW exists.
--
show {SHW}
  PK {SHW}

-- Season number SEA# of show SHW exists.
--
season {SHW, SEA#}
    PK {SHW, SEA#}

    FK {SHW} REFERENCES show {SHW}

-- Episode number EPI# of season number SEA#
-- of show SHW, in duration of DUR_E minutes, exists.
--
episode {SHW, SEA#, EPI#, DUR_E}
     PK {SHW, SEA#, EPI#}

     FK {SHW, SEA#} REFERENCES season {SHW, SEA#}

-- User USR watched DUR_W minutes of episode number EPI#
-- of season number SEA# of show SHW.
--
user_show {USR, SHW, SEA#, EPI#, DUR_W}
       PK {USR, SHW, SEA#, EPI#}

    FK1 {SHW, SEA#, EPI#} REFERENCES
episode {SHW, SEA#, EPI#}

    FK2 {USR} REFERENCES user {USR}

Примечание: 

All attributes (columns) NOT NULL

PK = Primary Key
FK = Foreign Key

Using suffix # to save on screen space.
OK for SQL Server and Oracle, for others use _NO.
For example, rename EPI# to EPI_NO.
0 голосов
/ 05 мая 2020

Краткий ответ: я думаю, что последний вариант - лучший вариант с точки зрения масштабируемого дизайна.

Более длинный ответ:

Последний вариант с показом <--> сезона <--> эпизоды, разделенные на отдельные таблицы, ближе к дизайну учебника. Третья нормальная форма , я думаю. Идея в том, что вы хотите уменьшить количество избыточных данных, насколько это возможно, чтобы минимизировать пространство для хранения. Минимизация избыточных данных - это общая лучшая практика. Разделив эти три, вы можете предотвратить репликацию атрибутов, которые указаны c для каждой вершины c.

Например, предположим, что вы отслеживаете такие атрибуты телешоу, как название, описание или средний рейтинг. Если вы ведете единую таблицу с шоу / сезоном / эпизодом, тогда атрибуты телешоу должны технически реплицироваться (т. Е. Избыточными) для каждого сезона и каждого эпизода, чтобы сохранить ограничения таблицы. И наоборот, разделение атрибутов телешоу позволяет избежать избыточных данных атрибутов. Это также помогает разрешить набор атрибутов расти / изменяться с течением времени.

Эта практика проектирования, хотя и сопряжена с вычислительными затратами, поскольку вам необходимо объединить структуры вместе в зависимости от вариантов использования. Например, если вам всегда нужно знать название шоу, сезон X и заголовок эпизода (атрибуты из каждой из таблиц), тогда вам нужно будет разработать необходимые логики соединения c для получения этих атрибутов. Эту стоимость можно уменьшить с помощью просмотра, открывающего другой набор решений.

К вашему комментарию о необходимости двух ключей. Следуя дизайну трех таблиц, вам, вероятно, понадобится какой-то первичный ключ для каждой таблицы. Если вы структурируете таблицу эпизодов со ссылочным ключом к сезону (и, возможно, к шоу), вам нужно будет использовать только ключ эпизода, поскольку вы можете отменить ссылку на сезон и телешоу из эпизода, используя команду join logi c. По сути, эпизода должно быть достаточно, чтобы по ссылке можно было определить сезон и телешоу.

...