Моделирование базы данных. От многих до многих отношений. Таблицы ссылок

Рассмотрим таблицу базы данных для user info like:

  

id, name, email

теперь рассмотрим, что у меня есть другая таблица для видео что-то вроде:

  

id, имя, описание, длина

Скажите, что между ними существует множество отношений, основанных на подписке. Очевидно, чтобы обработать отношения, вы создали бы третью таблицу ссылок user_video_link :

  

id, user_id, video_id

Я бы предположил, что кто-нибудь будет моделировать таблицу user с классом сущностей Пользователь и аналогично таблицу видео с Видео класса сущности, и пусть инфраструктура персистентности базы данных обрабатывает взаимосвязь между ними.

Теперь рассмотрим это, возникает требование, что есть возможность для пользователя установить, что они не заинтересованы в конкретном видео. Где я могу сохранить эту информацию, чтобы лучше всего соответствовать моей архитектуре? Я бы не думал, что изменение базовой структуры как user , так и видео будет делать что угодно. Давайте посмотрим на несколько вариантов со ссылками:

  1. Я мог бы создать другую таблицу ссылок, например: user_uninterested_video_link :
  

id, user_id, video_id

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

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

id, user_id, video_id, заинтересованный

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

Должно быть, что-то мне не хватает. Любой комментарий по этому вопросу от опытного мастера был бы очень признателен. Пожалуйста, просветите меня. Namaste.

3 голоса | спросил Bibek Khadka 3 MaramSat, 03 Mar 2018 09:14:46 +03002018-03-03T09:14:46+03:0009 2018, 09:14:46

1 ответ


3

Не будем игнорировать тот факт, что ваше решение 2 не семантически эквивалентно первому (поскольку оно позволит только моделировать статус interested для пользователя, у которого есть подписка на это видео). Вместо этого позвольте мне прямо ответить на ваш последний абзац:

  

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

Это правильно (и IMHO не необычно).

  

Кроме того, когда появляется что-то подобное, мы начинаем добавлять поля в таблицу ссылок

Это может произойти.

  

, и как-то таблица, предназначенная для базовой таблицы ссылок, становится таблицей, которая содержит всю бизнес-логику, что-то вроде таблицы богов.

Нет. Когда у вас есть дополнительные требования, вам нужно добавить их где-то в нужном месте в вашей модели данных, это не имеет никакого отношения, если правильное место является ссылкой или где-то еще. И если таблицы становятся «слишком большими» или начинают нарушать правила нормализации, в какой-то момент времени вам придется реорганизовать их, чтобы они не стали «таблицами богов». Это справедливо для таблицы any в вашей системе.

  

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

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

  

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

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

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

ответил Doc Brown 3 MaramSat, 03 Mar 2018 11:40:13 +03002018-03-03T11:40:13+03:0011 2018, 11:40:13

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132