Проект схемы реляционной БД - Как смоделировать отображение 1-к-1 прямо из набора полей объекта - PullRequest
Новая
       22

Проект схемы реляционной БД - Как смоделировать отображение 1-к-1 прямо из набора полей объекта

0 голосов
/ 24 ноября 2018

Я работаю над схемой MySQL (через Prisma datamodel) для объекта Customer в контексте электронной коммерции.Поскольку количество полей увеличилось (в том числе, скажем, отслеживание участия), у меня есть два возможных варианта: 

type Customer {
  email: String! @unique
  name: String
  birthDate: DateTime
  addresses: [Address!]!
  ...
  productsVisited: [Product!]!
  productsShared: [Product!]!
  productsSearched: [Product!]!
  ...
}

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

 type Customer {
  profile: CustomerProfile! @relation(name: "CustomerProfile", onDelete: CASCADE)
  addresses: [Address!]!
  ...
  productEngagements: ProductEngagement! @relation(name: "CustomerProductEngagements", onDelete: CASCADE)
  ...
}

type CustomerProfile {
  customer: Customer! @relation(name: "CustomerProfile", onDelete: SET_NULL)
  email: String! @unique
  name: String
  birthDate: DateTime
}

type ProductEngagement {
  customer: Customer! @relation(name: "CustomerProductEngagements", onDelete: SET_NULL)
  productsVisited: [Product!]!
  productsShared: [Product!]!
  productsSearched: [Product!]!
}

ВОПРОСЫ:

  1. Как правильно мыслить дизайном здесь?Я в настоящее время движим своими диаграммами ER и интуицией.Получаю ли я или теряю какое-либо преимущество в исполнении или гибкости, делая таблицу тонкой по сравнению с числом столбцов?

  2. Во втором методе должны ли запросы выполнять дополнительную работу для объединений таблиц?

Аннотация Вопрос:

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

Ответы [ 2 ]

0 голосов
/ 26 ноября 2018

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

При втором подходе, который вы обрисовали в общих чертах, Prisma действительно создаст таблицыдля CustomerProfile, ProductEngagement и всех других типов (как правило, Prisma отображает все определения типов из вашей модели данных в их собственные таблицы).Итак, как указал @ rick-james, в JOIN s могут быть издержки, которые необходимо выполнить при извлечении данных.

Каков правильный способ мышления при проектировании здесь?В настоящее время я руководствуюсь своими ER-диаграммами.

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

Также обратите внимание, что Prisma вскоре будет поддерживать встроенные типы , которые позволяют определять тип в Prisma.модель данных, которая не получает свою собственную таблицу, но где данные скорее хранятся в столбце JSON внутри таблицы не встроенного типа.В настоящее время это уже поддерживается при использовании Prisma с MongoDB, но еще не с SQL.Вы можете узнать больше об этой теме в запросе этой функции .

0 голосов
/ 26 ноября 2018

В РСУБД редко есть веская причина для разделения таблицы на две таблицы в соотношении 1: 1.JOIN объединение их в SELECT, безусловно, возможно, но добавляет некоторые накладные расходы, сложность кода и незначительное снижение производительности.

При этом я (редко) сталкивался со случаями, когдатакое «вертикальное разбиение» выгодно.

  • В одной таблице слишком много столбцов, и разбиение позволяет избежать превышения некоторого предела базы данных ... (Эта ситуация, вероятно, будет лучше обработанадругое решение.)
  • Некоторые столбцы громоздки и редко используются ... Перемещая их в отдельную таблицу, обычно избегают JOIN, и потенциальное снижение производительности для "громоздких"обычно избегают.
  • Вам нужно добавить несколько столбцов в огромную таблицу, но команда ALTER TABLE настолько затратна (подумайте, простои), что вы отчаянно пытаетесь найти способ ее избежать ... ТакойОтдельная таблица быстрая, простая и т. д. (Но, конечно, страдает от неудобства и т. д. необходимости JOIN.)
  • У вас есть набор столбцов, которые редко присутствуют втаблица ... Прежде чем разбивать их, вы намеревались заполнить столбцы NULLs (допустимое действие).Но после их разделения у вас просто нет строки в другой таблице.Затем вы используете LEFT JOIN, тем самым восстанавливая NULLs из воздуха.
...