Зачем мне делать внутреннее соединение в нечеткой области?

Question

Я только что натолкнулся на запрос, который делает inner join в непонятном поле. Я никогда не видел этого раньше, и я немного смущен этим использованием. Что-то вроде:

SELECT distinct all, my, stuff
FROM myTable
INNER JOIN myOtherTable
   ON myTable.nonDistinctField = myOtherTable.nonDistinctField
(WHERE some filters here...)

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

Answer 1

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

Answer 2

Я могу придумать причину - нечеткое поле - это внешний ключ.

Поле отличается во внешней таблице, но не в первой таблице.

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

Теперь вы получаете преимущества нормализации страны, но все еще отличные значения из таблицы адресов.

Слегка надуманный, но будет работать.

Answer 3

Одним из сценариев, который может быть правдоподобным, была бы система отчетности на основе даты, которая запрашивалась в течение определенного периода времени. Скажем, например, первые 3 месяца года. Затем можно объединить связанные данные из другой таблицы, как вы упомянули, где nonDistinctField - это year.month (yyyy.mm). Тем не менее, разрешение объединения может не иметь особого смысла, но вы можете использовать некоторую другую агрегатную функцию (SUM, AVG и т. Д.), Присоединенную к сгруппированному месяцу.

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

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

Answer 4

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