Это третья часть вводной серии статей о Prisma. Если вы не просматривали предыдущие статьи, вы можете найти их ниже.
Мы рассмотрели логику базы данных для простого сценария ведения блога, в котором есть две сущности базы данных. Пользователь и сообщение.
В этой статье мы рассмотрим практический подход к модерации этих объектов. Мы сосредоточимся на различных типах сопоставлений сущностей базы данных, которые могут иметь место, и на том, как схема Prisma помогает вам снять большую нагрузку в таких сценариях.
Поскольку основа, которую мы рассматриваем в этой статье, огромна, мы не будем рассматривать, как создавать операции CRUD в зависимости от вносимых нами изменений. Но вы можете найти соответствующий код в разделенных ветвях предыдущего репозитория, который мы использовали.
Разделенные ветки в конце статьи выглядят так.
В зависимости от мощности может быть 3 типа отношений.
- Один к одному (1-1)
- Один ко многим (1-м)
- Многие-ко-многим (m-n)
Мы учтем каждый из этих типов отношений и внесем соответствующие изменения.
Отношения один-к-одному (1-1)
В этой модификации мы будем делать объекты User & Profile следуя однозначному сопоставлению. Попутно мы также изменим несколько свойств объекта User.
Запись пользователя может иметь от нуля до одной записи профиля. У записи профиля должен быть Пользователь, иначе ее нельзя будет создать.
При желании вы можете назвать добавленное ограничение внешнего ключа с помощью атрибута @relation. В этом случае необходимо обновить обе модели.
Давайте запустим миграцию и посмотрим, как генерируется SQL-запрос.
npx prisma migrate dev --name “UserToProfile”
В зависимости от требований, Профиль может быть сделан обязательным для создания Пользователя.
Если мы попытаемся удалить модификатор необязательного типа, он будет недействителен.
Для этого на уровне базы данных нам нужно сохранить поле внешнего ключа, например profileId в таблице User.
Итак, мы добавим скалярное поле profileId в модель пользователя, на которое можно ссылаться в поле отношения profile. & ранее добавленное скалярное поле в профиле следует удалить, сделав сопоставление пользователя необязательным.
При попытке выполнить эту миграцию вам будет предложено предупреждение.
В случае, если нам нужно пропустить любое из вышеперечисленных условий. т.е. для независимого создания записей пользователя или профиля и сохранения взаимосвязей по желанию.
Решение о выборе объекта для хранения скалярного поля внешнего ключа во взаимно-однозначном сопоставлении зависит от вас.
Индивидуальные отношения к себе
Допустим, во время пандемии вы решили развернуть номинальную функцию для платформы блогов. Вы можете назначить Пользователя; В случае твоей смерти он / она может взять на себя ответственность.
В таком сценарии
- У пользователя может быть один или ноль номинаторов.
- У пользователя может быть один или ноль номинантов.
В этой ситуации мы должны добавить поле отношения к модели User, которое ссылается на себя.
Сгенерированный файл миграции выглядит так.
Отношения один-ко-многим (1-м)
Отношения между пользователями и сообщениями, которые мы построили до сих пор, имеют отношение «один ко многим». Соответственно, мы можем
- Создать пользователя с нулевым или большим количеством сообщений
- Создайте сообщение, которое всегда связано с пользователем
Подобно предыдущему сопоставлению «один в один», мы можем сделать сопоставление сообщения с пользователем необязательным. то есть в сообщении может быть от нуля до одного пользователя.
Что произойдет, если я использовал составной первичный ключ в таблице User вместо текущего поля идентификатора? Как мне отразить это в схеме Prisma?
В таком случае необходимо внести следующие изменения.
Если мы посмотрим на изменения миграции, относящиеся к этому.
Отношения "один-ко-многим"
Теперь, если вы решите создать должность менеджера блога, как бы вы изменили свою сущность «Пользователь»?
Один из способов - добавить несколько полей в модель пользователя.
Этим способом,
- Пользователь (или пользователь-участник блога) может иметь ноль или одного Менеджера.
- У Менеджера может быть от нуля до многих участников.
Сгенерированный файл миграции выглядит так.
Отношения "многие ко многим" (m-n)
В отношениях типа mn для реляционных баз данных мы создаем промежуточную таблицу, называемую таблица отношений (также другие термины, такие как Associate table, композиция таблицы, объединить таблицу или сводную таблицу подразумевает то же самое.)
Чтобы разобраться в этом, давайте добавим теги в нашу модель публикации. Одно сообщение может иметь от нуля до многих тегов и наоборот.
В Prisma Schema есть два способа определить отношение «многие ко многим» в зависимости от таблицы отношений.
- Явные отношения "многие ко многим"
- Неявные отношения "многие ко многим"
Явные отношения m-n
В явном соотношении m-n таблица промежуточных отношений представлена как модель в схеме Prisma.
В отличие от неявного отношения m-n, вы будете управлять таблицей отношений. Итак, вы можете следовать соглашению, которое лучше всего подходит.
Вы можете включить дополнительные метаданные, такие как дата создания тега (assignAt), назначенное лицо (assignBy). в таблице отношений.
Поскольку каждая модель должна иметь хотя бы один уникальный критерий, в котором есть только обязательные поля, мы добавим идентификатор нескольких полей с атрибутом @@id. (т.е. составной первичный ключ). Если вы думаете, что это с точки зрения данных, одно и то же сообщение не может иметь один и тот же тег более одного раза.
При выполнении миграции для этого изменения мы получаем следующий SQL-запрос.
Неявные отношения m-n
В неявном отношении m-n поля отношения определены как списки в двух моделях. Хотя таблица отношений существует в базовой базе данных, она управляется Prisma & не проявляется в схеме Prisma.
Сгенерированный SQL-запрос миграции выглядит следующим образом.
Автоматически сгенерированная таблица отношений в неявном отношении m-n следует определенному соглашению.
Чтобы следовать неявному соотношению m-n, обе модели должны иметь один идентификатор поля (@id)
Отношения многие-ко-многим с самими собой
Отношение m-n к себе всегда подразумевается. Простым примером этого является добавление подписчиков в модель User.
Миграция дает сгенерированный SQL, как показано ниже.
Помимо невозможности добавить дополнительные метаданные, вы не можете модерировать ссылочные действия в неявном отношении m-n.
Вывод
Мы рассмотрели большинство типов отношений, которые могут иметь место, с помощью нашего простого сценария блога.
Надеюсь, эта статья поможет вам понять, как работать с Prisma при управлении сопоставлениями различных сущностей в реляционной базе данных.
В следующей статье мы рассмотрим один важный недостающий элемент в отображении сущностей, который работает в Prisma: Ссылочные действия.
Больше контента на plainenglish.io
