СОЕДИНЕНИЕ mysql - левое, правое или внешнее?

#mysql

Вопрос:

У меня есть 2 таблицы со следующими столбцами: Таблица 1

  -------------- --------------- ------ ----- --------- ---------------- 
| Field | Type | Null | Key | Default | Extra |
 -------------- --------------- ------ ----- --------- ---------------- 
| id | int(11) | NO | PRI | NULL | auto_increment |
| symbol | varchar(45) | NO | MUL | NULL | |
| v_dt | date | NO | | NULL | |
| e_dt | date | NO | | NULL | |
| col_s | decimal(10,4) | NO | | NULL | |
| col_o | decimal(10,4) | NO | | NULL | |
| col_b | decimal(10,4) | NO | | NULL | |
| col_a | decimal(10,4) | NO | | NULL | |
| col_l | decimal(10,4) | NO | | NULL | |
| col_v | bigint(20) | NO | | NULL | |
| col_t | enum('a','b') | NO | | NULL | |
 -------------- --------------- ------ ----- --------- ----------------

и таблица 2:

  ------------ --------------- ------ ----- --------- ------- 
| Field | Type | Null | Key | Default | Extra |
 ------------ --------------- ------ ----- --------- ------- 
| t_date | date | NO | PRI | NULL | |
| e_date | date | NO | | NULL | |
| symbol | varchar(45) | NO | PRI | NULL | |
| col_i | decimal(10,6) | NO | | NULL | |
| col_b | decimal(10,6) | NO | | NULL | |
| col_d | decimal(10,6) | NO | | NULL | |
| col_g | decimal(10,6) | NO | | NULL | |
| col_v | decimal(10,6) | NO | | NULL | |
| col_t | decimal(10,6) | NO | | NULL | |
| col_r | decimal(10,6) | NO | | NULL | |
 ------------ --------------- ------ ----- --------- -------

Я хочу получить table1.col_b, table1.col_a и table2.col_d
итак, я написал следующее

 SELECT col_b, col_a, col_d FROM table1 LEFT JOIN table2 ON table1.symbol=table2.symbol;

но вместо того, чтобы возвращать 40 строк, которые он должен иметь, он продолжал работать, чтобы получить 4000 строк с нерелевантными данными, поэтому я предполагаю, что я неправильно написал СОЕДИНЕНИЕ.
Не могли бы вы, пожалуйста. дайте мне знать, как правильно написать это, чтобы получить требуемые данные. спасибо!
результат ВНУТРЕННЕГО СОЕДИНЕНИЯ (я изменил запрос, включив даты, чтобы результаты имели больше смысла, я надеюсь)

 SELECT v_dt, e_dt, col_d FROM table1 INNER JOIN table2 ON table1.symbol=table2.symbol;

| 2011-09-26   | 2011-11-18 |   2.030130 |
| 2011-09-27   | 2011-11-18 |   2.030130 |
| 2011-09-28   | 2011-11-18 |   2.030130 |
| 2011-09-29   | 2011-11-18 |   2.030130 |
| 2011-09-30   | 2011-11-18 |   2.030130 |
| 2011-10-03   | 2011-11-18 |   2.030130 |
| 2011-10-04   | 2011-11-18 |   2.030130 |
| 2011-10-05   | 2011-11-18 |   2.030130 |
| 2011-10-06   | 2011-11-18 |   2.030130 |
| 2011-10-07   | 2011-11-18 |   2.030130 |
| 2011-10-10   | 2011-11-18 |   2.030130 |
| 2011-10-11   | 2011-11-18 |   2.030130 |
| 2011-10-12   | 2011-11-18 |   2.030130 |
| 2011-10-13   | 2011-11-18 |   2.030130 |
| 2011-10-14   | 2011-11-18 |   2.030130 |
| 2011-08-09   | 2011-11-18 |   1.628250 |
| 2011-08-10   | 2011-11-18 |   1.628250 |
| 2011-08-11   | 2011-11-18 |   1.628250 |
| 2011-08-12   | 2011-11-18 |   1.628250 |
| 2011-08-15   | 2011-11-18 |   1.628250 |
| 2011-08-16   | 2011-11-18 |   1.628250 |
| 2011-08-17   | 2011-11-18 |   1.628250 |
| 2011-08-18   | 2011-11-18 |   1.628250 |
| 2011-08-19   | 2011-11-18 |   1.628250 |
| 2011-08-22   | 2011-11-18 |   1.628250 |
| 2011-08-24   | 2011-11-18 |   1.628250 |
| 2011-08-25   | 2011-11-18 |   1.628250 |
| 2011-08-26   | 2011-11-18 |   1.628250 |
| 2011-08-29   | 2011-11-18 |   1.628250 |
| 2011-08-30   | 2011-11-18 |   1.628250 |
| 2011-08-31   | 2011-11-18 |   1.628250 |
| 2011-09-01   | 2011-11-18 |   1.628250 |
| 2011-09-02   | 2011-11-18 |   1.628250 |
| 2011-09-06   | 2011-11-18 |   1.628250 |
| 2011-09-07   | 2011-11-18 |   1.628250 |
| 2011-09-08   | 2011-11-18 |   1.628250 |
| 2011-09-09   | 2011-11-18 |   1.628250 |
| 2011-09-13   | 2011-11-18 |   1.628250 |
| 2011-09-14   | 2011-11-18 |   1.628250 |
| 2011-09-15   | 2011-11-18 |   1.628250 |
| 2011-09-16   | 2011-11-18 |   1.628250 |
| 2011-09-19   | 2011-11-18 |   1.628250 |
| 2011-09-20   | 2011-11-18 |   1.628250 |
| 2011-09-21   | 2011-11-18 |   1.628250 |
| 2011-09-22   | 2011-11-18 |   1.628250 |
| 2011-09-23   | 2011-11-18 |   1.628250 |
| 2011-09-26   | 2011-11-18 |   1.628250 |
| 2011-09-27   | 2011-11-18 |   1.628250 |
| 2011-09-28   | 2011-11-18 |   1.628250 |
| 2011-09-29   | 2011-11-18 |   1.628250 |
| 2011-09-30   | 2011-11-18 |   1.628250 |
| 2011-10-03   | 2011-11-18 |   1.628250 |
| 2011-10-04   | 2011-11-18 |   1.628250 |
| 2011-10-05   | 2011-11-18 |   1.628250 |
| 2011-10-06   | 2011-11-18 |   1.628250 |
| 2011-10-07   | 2011-11-18 |   1.628250 |
| 2011-10-10   | 2011-11-18 |   1.628250 |
| 2011-10-11   | 2011-11-18 |   1.628250 |
| 2011-10-12   | 2011-11-18 |   1.628250 |
| 2011-10-13   | 2011-11-18 |   1.628250 |
| 2011-10-14   | 2011-11-18 |   1.628250 |
| 2011-08-09   | 2011-11-18 |   1.254390 |
| 2011-08-10   | 2011-11-18 |   1.254390 |
| 2011-08-11   | 2011-11-18 |   1.254390 |
| 2011-08-12   | 2011-11-18 |   1.254390 |
| 2011-08-15   | 2011-11-18 |   1.254390 |
| 2011-08-16   | 2011-11-18 |   1.254390 |
| 2011-08-17   | 2011-11-18 |   1.254390 |
| 2011-08-18   | 2011-11-18 |   1.254390 |
| 2011-08-19   | 2011-11-18 |   1.254390 |
| 2011-08-22   | 2011-11-18 |   1.254390 |
| 2011-08-24   | 2011-11-18 |   1.254390 |
| 2011-08-25   | 2011-11-18 |   1.254390 |
| 2011-08-26   | 2011-11-18 |   1.254390 |
| 2011-08-29   | 2011-11-18 |   1.254390 |
| 2011-08-30   | 2011-11-18 |   1.254390 |
| 2011-08-31   | 2011-11-18 |   1.254390 |
| 2011-09-01   | 2011-11-18 |   1.254390 |
| 2011-09-02   | 2011-11-18 |   1.254390 |
| 2011-09-06   | 2011-11-18 |   1.254390 |
| 2011-09-07   | 2011-11-18 |   1.254390 |
| 2011-09-08   | 2011-11-18 |   1.254390 |
| 2011-09-09   | 2011-11-18 |   1.254390 |
| 2011-09-13   | 2011-11-18 |   1.254390 |
| 2011-09-14   | 2011-11-18 |   1.254390 |
| 2011-09-15   | 2011-11-18 |   1.254390 |
| 2011-09-16   | 2011-11-18 |   1.254390 |
| 2011-09-19   | 2011-11-18 |   1.254390 |
| 2011-09-20   | 2011-11-18 |   1.254390 |
| 2011-09-21   | 2011-11-18 |   1.254390 |
| 2011-09-22   | 2011-11-18 |   1.254390 |
| 2011-09-23   | 2011-11-18 |   1.254390 |
| 2011-09-26   | 2011-11-18 |   1.254390 |
| 2011-09-27   | 2011-11-18 |   1.254390 |
| 2011-09-28   | 2011-11-18 |   1.254390 |
| 2011-09-29   | 2011-11-18 |   1.254390 |
| 2011-09-30   | 2011-11-18 |   1.254390 |
| 2011-10-03   | 2011-11-18 |   1.254390 |
| 2011-10-04   | 2011-11-18 |   1.254390 |
| 2011-10-05   | 2011-11-18 |   1.254390 |
| 2011-10-06   | 2011-11-18 |   1.254390 |
| 2011-10-07   | 2011-11-18 |   1.254390 |
| 2011-10-10   | 2011-11-18 |   1.254390 |
| 2011-10-11   | 2011-11-18 |   1.254390 |
| 2011-10-12   | 2011-11-18 |   1.254390 |
| 2011-10-13   | 2011-11-18 |   1.254390 |
| 2011-10-14   | 2011-11-18 |   1.254390 |
| 2011-08-09   | 2011-11-18 |   1.019710 |
| 2011-08-10   | 2011-11-18 |   1.019710 |
| 2011-08-11   | 2011-11-18 |   1.019710 |
| 2011-08-12   | 2011-11-18 |   1.019710 |
| 2011-08-15   | 2011-11-18 |   1.019710 |
| 2011-08-16   | 2011-11-18 |   1.019710 |
| 2011-08-17   | 2011-11-18 |   1.019710 |
| 2011-08-18   | 2011-11-18 |   1.019710 |
| 2011-08-19   | 2011-11-18 |   1.019710 |

все, что я надеялся получить, это следующие 2 столбца из таблицы 1, а 3-й столбец — col_d из таблицы 2. следовательно, я ожидал 45 строк.

  -------------- ------------ 
| 2011-08-09   | 2013-01-18 |
| 2011-08-10   | 2013-01-18 |
| 2011-08-11   | 2013-01-18 |
| 2011-08-12   | 2013-01-18 |
| 2011-08-15   | 2013-01-18 |
| 2011-08-16   | 2013-01-18 |
| 2011-08-17   | 2013-01-18 |
| 2011-08-18   | 2013-01-18 |
| 2011-08-19   | 2013-01-18 |
| 2011-08-22   | 2013-01-18 |
| 2011-08-24   | 2013-01-18 |
| 2011-08-25   | 2013-01-18 |
| 2011-08-26   | 2013-01-18 |
| 2011-08-29   | 2013-01-18 |
| 2011-08-30   | 2013-01-18 |
| 2011-08-31   | 2013-01-18 |
| 2011-09-01   | 2013-01-18 |
| 2011-09-02   | 2013-01-18 |
| 2011-09-06   | 2013-01-18 |
| 2011-09-07   | 2013-01-18 |
| 2011-09-08   | 2013-01-18 |
| 2011-09-09   | 2013-01-18 |
| 2011-09-13   | 2013-01-18 |
| 2011-09-14   | 2013-01-18 |
| 2011-09-15   | 2013-01-18 |
| 2011-09-16   | 2013-01-18 |
| 2011-09-20   | 2013-01-18 |
| 2011-09-21   | 2013-01-18 |
| 2011-09-22   | 2013-01-18 |
| 2011-09-23   | 2013-01-18 |
| 2011-09-26   | 2013-01-18 |
| 2011-09-27   | 2013-01-18 |
| 2011-09-28   | 2013-01-18 |
| 2011-09-29   | 2013-01-18 |
| 2011-09-30   | 2013-01-18 |
| 2011-10-03   | 2013-01-18 |
| 2011-10-04   | 2013-01-18 |
| 2011-10-05   | 2013-01-18 |
| 2011-10-06   | 2013-01-18 |
| 2011-10-07   | 2013-01-18 |
| 2011-10-10   | 2013-01-18 |
| 2011-10-11   | 2013-01-18 |
| 2011-10-12   | 2013-01-18 |
| 2011-10-13   | 2013-01-18 |
| 2011-10-14   | 2013-01-18 |
 -------------- ------------ 
45 rows in set (0.02 sec)

добавление ГРУППЫ С ПОМОЩЬЮ v_dt, e_dt сократило ее до 45 строк, а столбцы таблицы1 являются правильными. единственная проблема в том, что теперь он показывает то же значение (5.530000) для table2.col_d, что не так, как должно быть:-(

  -------------- ------------ ---------- 
| 2011-08-09   | 2013-01-18 | 5.530000 |
| 2011-08-10   | 2013-01-18 | 5.530000 |
| 2011-08-11   | 2013-01-18 | 5.530000 |
| 2011-08-12   | 2013-01-18 | 5.530000 |
| 2011-08-15   | 2013-01-18 | 5.530000 |
| 2011-08-16   | 2013-01-18 | 5.530000 |
| 2011-08-17   | 2013-01-18 | 5.530000 |
| 2011-08-18   | 2013-01-18 | 5.530000 |
| 2011-08-19   | 2013-01-18 | 5.530000 |
| 2011-08-22   | 2013-01-18 | 5.530000 |
| 2011-08-24   | 2013-01-18 | 5.530000 |
| 2011-08-25   | 2013-01-18 | 5.530000 |
| 2011-08-26   | 2013-01-18 | 5.530000 |
| 2011-08-29   | 2013-01-18 | 5.530000 |
| 2011-08-30   | 2013-01-18 | 5.530000 |
| 2011-08-31   | 2013-01-18 | 5.530000 |
| 2011-09-01   | 2013-01-18 | 5.530000 |
| 2011-09-02   | 2013-01-18 | 5.530000 |
| 2011-09-06   | 2013-01-18 | 5.530000 |
| 2011-09-07   | 2013-01-18 | 5.530000 |
| 2011-09-08   | 2013-01-18 | 5.530000 |
| 2011-09-09   | 2013-01-18 | 5.530000 |
| 2011-09-13   | 2013-01-18 | 5.530000 |
| 2011-09-14   | 2013-01-18 | 5.530000 |
| 2011-09-15   | 2013-01-18 | 5.530000 |
| 2011-09-16   | 2013-01-18 | 5.530000 |
| 2011-09-20   | 2013-01-18 | 5.530000 |
| 2011-09-21   | 2013-01-18 | 5.530000 |
| 2011-09-22   | 2013-01-18 | 5.530000 |
| 2011-09-23   | 2013-01-18 | 5.530000 |
| 2011-09-26   | 2013-01-18 | 5.530000 |
| 2011-09-27   | 2013-01-18 | 5.530000 |
| 2011-09-28   | 2013-01-18 | 5.530000 |
| 2011-09-29   | 2013-01-18 | 5.530000 |
| 2011-09-30   | 2013-01-18 | 5.530000 |
| 2011-10-03   | 2013-01-18 | 5.530000 |
| 2011-10-04   | 2013-01-18 | 5.530000 |
| 2011-10-05   | 2013-01-18 | 5.530000 |
| 2011-10-06   | 2013-01-18 | 5.530000 |
| 2011-10-07   | 2013-01-18 | 5.530000 |
| 2011-10-10   | 2013-01-18 | 5.530000 |
| 2011-10-11   | 2013-01-18 | 5.530000 |
| 2011-10-12   | 2013-01-18 | 5.530000 |
| 2011-10-13   | 2013-01-18 | 5.530000 |
| 2011-10-14   | 2013-01-18 | 5.530000 |
 -------------- ------------ ----------

это обновленный запрос.
select table1.v_dt, table1.e_dt, table2.col_b from table1 inner join table2 on table1.symbol=table2.symbol group by v_dt, e_dt;
чтобы еще больше сузить результаты, я также выполнил
select table1.v_dt, table1.e_dt, table2.col_b from table1 inner join table2 on table1.symbol='P00055000' group by v_dt, e_dt; но я все равно получаю те же результаты, а затем

 select symbol, count(*) from table2 where symbol='P00055000' group by symbol;

 -------------------- ---------- 
| P00055000 |       40 |
 -------------------- ---------- 
1 row in set (0.02 sec)

1. Почему «должно быть» вернуло 40 строк. Не ясно, откуда взялось это число. Это количество строк в одной из таблиц? Если да, то получаете ли вы много дубликатов или разных значений? Если разные значения, каковы критерии выбора строк?

2. Я вручную выполнил поиск, поэтому знаю, что есть только 40 строк. Он возвращает несколько строк с col_d как NULL, а для тех, у кого правильные результаты, он возвращает дубликаты и трипликаты.

3. Дубликаты могут быть не из-за типа соединения, а, скорее всего, из-за неправильных условий соединения (или проблем с данными)

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

5. Я только что отредактировал свой пост с результатами выполнения нового запроса. это усеченная версия результатов.

Ответ №1:

Если у вас есть две таблицы A и B:

ЛЕВОЕ СОЕДИНЕНИЕ B = выбрать все строки A и любые строки из B, которые соответствуют условию соединения, или NULL, если B не соответствует условию соединения
ПРАВОЕ СОЕДИНЕНИЕ B = выбрать все строки B и любые строки из A, которые соответствуют условию соединения, или NULL, если A не соответствует условию соединения
ВНУТРЕННЕЕ СОЕДИНЕНИЕ B = выбрать только те строки из A и B, которые соответствуют условию соединения

Для любого столбца, выбранного в соединениях СЛЕВА / СПРАВА в таблице соединений, будет присутствовать нулевое значение, если строка не соответствует условию соединения.

Например, скажем, у нас есть две таблицы

 Table A (id, name, description)
Table B (id, a_id, group_id, date)

Когда мы выполняем ЛЕВОЕ СОЕДИНЕНИЕ ниже, мы ожидаем, что результаты запроса вернут NULL для B.group_id и B.date, если не удалось найти запись в таблице B.

 SELECT A.id, A.name, A.description, B.group_id, B.date FROM A
LEFT JOIN B ON B.a_id=A.id

В результате

 id | name | description | group_id | date
1  | Test | Test        | 2        | 2011-3-4
2  | Test | Test        | NULL     | NULL

Как вы можете видеть, в первой строке успешно найдена запись как в A, так и В B, которая соответствует условиям соединения. С другой стороны, строка 2 не смогла найти соответствующую запись в B, поэтому вместо нее были добавлены нулевые значения.

Давайте посмотрим на ПРАВОЕ СОЕДИНЕНИЕ. На самом деле это обратное ЛЕВОМУ СОЕДИНЕНИЮ. Мы ожидаем, что все записи из B будут содержать свои данные, но если запись в A не совпадает, она будет СОДЕРЖАТЬ НУЛИ.

 SELECT A.id, A.name, A.description, B.group_id, B.date FROM A
RIGHT JOIN B ON B.a_id=A.id

В результате

 id   | name | description | group_id | date
1    | Test | Test        | 2        | 2011-3-4
NULL | NULL | NULL        | 3        | 2011-5-6

Как вы можете видеть, в первой строке успешно найдена запись как в A, так и В B, которая соответствует условиям соединения (таким же, как для соединения СЛЕВА). С другой стороны, строка 2 не смогла найти запись в A, которая соответствовала, поэтому вместо этого добавила нулевые значения.

Наконец, давайте посмотрим на ВНУТРЕННЕЕ СОЕДИНЕНИЕ. ВНУТРЕННЕЕ СОЕДИНЕНИЕ обычно является наиболее полезным объединением, поскольку оно возвращает только записи, совпадающие как в A, так и В B, что чаще всего является тем, что вы ищете

 SELECT A.id, A.name, A.description, B.group_id, B.date FROM A
INNER JOIN B ON B.a_id=A.id

В результате

 id   | name | description | group_id | date
1    | Test | Test        | 2        | 2011-3-4

Теперь мы возвращаем только ту запись, которая совпадает как в A, так и в B, и игнорируем все остальные. Надеюсь, это прояснит ситуацию для вас.

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

2. В table2 может быть несколько строк, которые соответствуют условию соединения, поэтому вы, конечно, получите повторяющиеся строки в этом сценарии. Если вы ищете только уникальные значения v_dt, e_dt, вам нужно добавить a GROUP BY v_dt, e_dt в конец вашего запроса

3. спасибо methodin, группа by сократила его до правильного количества строк, и я опубликовал отредактированные результаты — столбцы 1 и 2 верны. единственный оставшийся сбой — это значения из table2 (в столбце 3), поскольку они просто повторяют одно значение.

4. Можете ли вы добавить новый полный запрос с помощью групповых bys? Вы должны проверить данные, выполнив a SELECT symbol,count(*) FROM table2 GROUP BY symbol это сообщит, есть ли у вас повторяющиеся строки в table2, которые дадут вам дополнительные строки в соединении. Если это так, вам придется еще немного отфильтровать table2, чтобы получить только одну строку в соединении.

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

Ответ №2:

Я думаю, вы ищете inner join . Соединение по левому краю возвращает все записи из таблицы1 и либо соответствующие значения таблицы2, либо обнуляет, если нет соответствующей таблицы2.

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

http://en.wikipedia.org/wiki/Join_ (SQL)

Причина, по которой вы получаете так много записей, заключается в том, что соединение возвращает декартово произведение двух таблиц. Например, если у вас есть таблица с 10 записями, а другая с 20 записями, в итоге у вас будет 200 записей. Это, очевидно, бесполезно само по себе, поэтому вы добавляете условие соединения, чтобы возвращать только те записи, которые логически сочетаются друг с другом, обычно на основе отношения внешнего ключа. Итак, для:

 Table1 - Table1Key, Table1Value
Table2 - Table2Key, Table1KeyReference, Table2Value

and the values

Table1
1,'1'
2,'2'
3,'3'
4,'4'
5,'5'

Table2
1,1,'1-1'
2,1,'1-2'
3,2,'2-3'

С этими данными выполняется следующее утверждение

 select *
    from Table1
        inner join Table2

ВОЗВРАТ

 Table1Key,Table1Value,Table2Key,Table1KeyReference, Table2Value
1,'1',1,1,'1-1'
1,'1',2,1,'1-2'
1,'1',3,2,'2-3'
2,'2',1,1,'1-1'
2,'2',2,1,'1-2'
2,'2',3,2,'2-3'
....

И т.д. Из этих 15 комбинаций только «правильные», поэтому нам нужно добавить условие соединения:

 select *
    from Table1
        inner join Table2 on(Table1.Table1Key=Table2.Table1KeyReference)

Которое возвращает:

 1,'1',1,1,'1-1'
1,'1',2,1,'1-2'
2,'2',3,2,'2-3'

Причина, по которой это возвращает только 3 в Table2, заключается в том, что каждая строка в Table2 соответствует 1 и только строке в Table1.

Проблема в вашем случае заключается в том, что вы не определили эту связь между двумя таблицами. Если в P00055000 вашей второй таблице 40 символов, а в первой — 2 с этим символом, то вы получите 80 результатов от вашего объединения. Если есть 40 разных символов, каждый из которых содержит дополнительные 40 строк во второй таблице и 2 в первой, то в итоге получится 3200 строк и т.д. Большая часть этих данных может быть бессмысленной, и это потому, что вы не четко определили, какая связь существует между двумя таблицами.

Итак, все сказано, какие результаты вы хотите, когда выполняете свой выбор? Для данной строки в Table1, если вы соединили ее с каждой строкой из таблицы 2, какие строки вы хотели бы вернуть? Оттуда вы должны быть в состоянии создать правильное условие соединения. Если эти две строки тесно связаны (родительский потомок и т. Д.), Вам следует рассмотреть возможность повторного факторинга таблиц для объединения по связям первичного / внешнего ключа и удаления дублирующихся данных.

Кроме того, я предполагаю, что это не ваши настоящие имена таблиц и полей. Если они есть, измените их на что-то значимое. Длина имен ваших столбцов не влияет на производительность запросов, но значительно упрощает совместное использование, обсуждение и модификацию вашего кода.