Почему INNER JOIN создает больше записей, чем оригинальный файл? - PullRequest
0 голосов
/ 14 июня 2019

У меня есть две таблицы.Таблица A и Таблица B. Таблица A имеет 40516 строк и регистрирует продажи по seller_id.Первый столбец в Таблице A - это seller_id, который повторяется каждый раз, когда совершается продажа.

Пример: Таблица A (40516 строк)

seller_id | item | cost
------------------------
   1      | dog  | 5000
   1      | cat  | 50
   4      |lizard| 80
   5      |bird  | 20
   5      |fish  | 90

Идентификатор продавца также присутствует в Таблице B и также содержит соответствующее имя продавца.

Пример: таблица B (5851 строка)

seller_id | seller_name
-------------------------
   1      | Dog and Cat World INC
   4      | Reptile Love.com
   5      | Ocean Dogs Inc

Я хочу объединить эти две таблицы, но отображать только имя продавца из таблицы B и все другие столбцы из таблицы A. Когда ясделать это с INNER JOIN Я получаю 40864 строки (348 дополнительных строк).Разве запрос не должен генерировать только исходные 40516 строк?

Также не уверен, имеет ли это значение, но seller_id может содержать несколько нулей перед числом (например, 0000845, 0000549).

Я осмотрелся здесь и не нашел ответа.Я пытался использовать соединения LEFT и RIGHT и получал одинаковые результаты для одного и еще больше результатов для другого.

Пример кода SQL:

SELECT public.table_B.seller_name, *
FROM public.table_A
INNER JOIN public.table_B ON public.table_A.seller_id = 
public.table_B.seller_id;

Ожидаемые результаты:

seller_name           | seller_id | item | cost
------------------------------------------------
Dog and Cat World INC |    1      | dog  | 5000
Dog and Cat World INC |    1      | cat  | 50
Reptile Love.com      |    4      |lizard| 80
Ocean Dogs Inc        |    5      |bird  | 20
Ocean Dogs Inc        |    5      |fish  | 90

Я ожидал, что результаты будут содержать такое же количество строк в Таблице А. Вместо этого я собираю совпадающие имена и дополнительные 348 строк ...

Обновление:

Я изменил "unique_id "to" seller_id "в вопросе.

Полагаю, мне следовало выбрать лучшее имя для unique_id в исходном примере.Я не хотел, чтобы это было уникально в смысле ключа.Это просто идентификатор продавца, который повторяется каждый раз, когда происходит продажа (в таблице A).Идентификатор продавца повторяется в Таблице А, потому что он должен.Я просто хочу соединить идентификаторы продавца с именами продавца.

Еще раз спасибо всем за помощь!

Ответы [ 3 ]

1 голос
/ 14 июня 2019

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

Запустите этот запрос, чтобы найти дубликаты:

select unique_id
from table_b
group by unique_id
having count(*) > 1;

Вы можете исправить запрос, используя distinct on:

SELECT b.seller_name, a.*
FROM public.table_A a JOIN
     (SELECT DISTINCT ON (b.unique_id) b.*
      FROM public.table_B b
      ORDER BY b.unique_id
     ) b
     ON a.unique_id = b.unique_id;

В этом случае вы можете получить меньше записей, если совпадений нет.Чтобы это исправить, используйте LEFT JOIN.

0 голосов
/ 20 июня 2019

Гордон Линофф был прав.Идентификатор seller_id (ранее указанный как unique_id) действительно дублировался во всем наборе данных.Я по глупости предположил иначе.Также у seller_name было много дубликатов!В конце концов, мне пришлось использовать функцию CONCAT (), чтобы соединить seller_id со вторым идентификатором, чтобы создать тип внешнего ключа.После того, как я это сделал, соединение сработало как положено.Спасибо всем!

0 голосов
/ 14 июня 2019

Поскольку уникальный идентификатор * столбец 1002 * равен не уникален .

...