Как лучше всего объяснить, на каких полях должен присоединяться пользователь?

Question

Мне нужно объяснить кому-то, как они могут определить, к каким полям из нескольких таблиц / представлений они должны присоединяться.Какие-либо предложения?Я знаю, как это сделать, но с трудом пытаюсь объяснить это.

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

Должен ли я где-нибудь работать в PK и FK?

Answer 1

Хотя присоединение PK к FK действительно типично, любой разговор о JOIN предложениях, которые вращаются только вокруг PK и FK, довольно ограничен

Например, у меня было это FROM предложение в недавнем SQL ответе , которое я дал

FROM
  YourTable firstNames 
   LEFT JOIN YourTable  lastNames 
       ON firstnames.Name = lastNames.Name
         AND lastNames.NameType  =2
          and firstnames.FrequencyPercent < lastNames.FrequencyPercent

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

Также вам даже не нужно соединять один стол с другим. Вы можете объединять встроенные запросы друг с другом, которые, конечно, не могут иметь Ключ.

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

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

Answer 2

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

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

Также полезно написать ваш запрос в виде предложения: «Я хочу видеть, как Таблица А взаимодействует с Таблицей Б». Затем создайте запрос с использованием только идентификатора, отметив, что если вы хотите знать, что «Таблица A все время была в одном и том же почтовом индексе с таблицей B», то вы бы присоединились по почтовому индексу.

Answer 3

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

Проще говоря, ищите столбцы со значениями, которые совпадают междутаблицы / представления.Желательно, чтобы совпадения были точными, но может потребоваться какое-то массирование.

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

Наличие первичного ключа не означает, что для запроса необходимы критерии, поэтому я бы упустил эту деталь (в зависимости от аудитории).

Я бы порекомендовал атаковатьжелаемый результат устанавливается, начиная с нужных столбцов и возвращаясь оттуда.Если в наборе результатов содержится более одного столбца таблицы, сфокусируйтесь на таблице, столбцы которой должны сначала возвращать различные результаты, а затем постепенно добавляйте объединения, проверяя набор результатов между каждым добавлением JOIN, чтобы убедиться, что результаты остаются прежними.В противном случае необходимо пересмотреть СОЕДИНЕНИЕ или, если действительно требуется СОЕДИНЕНИЕ против IN или EXISTS.

Answer 4

Исходя из теории, в идеале вы должны определить первичные ключи для всех таблиц и соединить таблицы, используя первичный ключ с соответствующим полем или полями (внешним ключом) в другой таблице.
Даже если вы не определили или они не определены как первичные ключи, вы должны убедиться, что поля однозначно идентифицируют записи в таблице и что они должны быть правильно проиндексированы.
Например, предположим, что таблица person имеет SSN и поле с водительскими правами. SSN можно рассматривать и помечать как «первичный ключ», но если вы присоедините эту таблицу к таблице «драйверов», которая может не иметь SSN, но имеет водительские права #, вы можете присоединить их к полю водительских прав. (даже если он не помечен как первичный ключ), но вы должны убедиться, что поле правильно проиндексировано в обеих таблицах.

Answer 5

Пользователь обычно не должен делать объединения. У пользователя должен быть интерфейс, позволяющий ему получать данные, которые им нужны, так, как они ему нужны. Если у вас нет ресурсов разработчика, чтобы сделать это, то вы застрянете с этой проблемой необходимости обучать пользователя техническим деталям. Вы также должны быть очень осторожными в отношении того, какой ущерб может нанести пользователь. Есть ли у них права на обновление данных? Я надеюсь, что они случайно не делают DELETE FROM Table без предложения WHERE. Даже если вы ограничите их разрешения, плохо написанный запрос может привести к повреждению сервера базы данных или блокированию ресурсов, что вызовет проблемы для других пользователей (и больше работы для вас).

Если у вас нет выбора, тогда я думаю, что вам обязательно нужно научить их первичным и внешним ключам, даже если вы их так не называете. Укажите, что идентификатор вашей таблицы (или какой-либо другой PK) идентифицирует строку. Затем объясните, как идентификатор отображается в других таблицах, чтобы показать взаимосвязь. Например: «Смотрите, в таблице адресов у нас есть person_id, который сообщает нам, кому принадлежит этот адрес».

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

Answer 6

Мне кажется, что ни вы, ни человек, которому вы пытаетесь помочь, не понимают, как устроена эта конкретная база данных, и, возможно, даже не понимаете базовых основ базы данных, таких как ПК и ФК. Чаще всего PK из одной таблицы соединяется с FK с другой таблицей.

Предполагая, что в базе данных имеются соответствующие PK и FK, это, вероятно, очень поможет в создании диаграммы ER. Это значительно облегчит понимание концепции соединения.

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

Answer 7

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

Дайте им примеры присоединения к нему и присоединения без него.

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