сравнивая столбец с самим собой в предложении WHERE оракула SELECT - PullRequest
Новая
       17

сравнивая столбец с самим собой в предложении WHERE оракула SELECT

3 голосов
/ 29 июня 2010

У меня есть многотабличный запрос SELECT, который сравнивает значения столбца с самим собой, как показано ниже: 

SELECT * FROM table1 t1,table2 t2
      WHERE t1.col1=t2.col1  --Different tables,So OK.
      AND t1.col1=t1.col1    --Same tables??
      AND t2.col1=t2.col1    --Same tables??

Это кажется мне излишним.Мой вопрос: будет ли их удаление влиять на логику / производительность?

Заранее спасибо.

Ответы [ 3 ]

10 голосов
/ 29 июня 2010

Это кажется избыточным, его единственный эффект - удаление строк, имеющих значения NULL в этих столбцах.Убедитесь, что столбцы НЕ ПУСТО (NULL), прежде чем удалять эти пункты.

Если столбцы могут иметь значение NULL, вы можете смело заменять эти строки на (легче читать, легче поддерживать): 

  AND t1.col1 IS NOT NULL
  AND t2.col1 IS NOT NULL

Обновление после комментария Джеффри

Вы абсолютно правы, я не знаю, как я сам этого не видел: условие соединения t1.col1=t2.col1 подразумевает, что толькостроки со столбцами соединения, не равными NULL, будут рассматриваться.Поэтому пункты tx.col1=tx.col1 полностью избыточны и могут быть безопасно удалены.

0 голосов
/ 29 июня 2010

  1. Да, условия явно избыточны, поскольку они идентичны! 

    SELECT * FROM table1 t1,table2 t2
WHERE t1.col1=t2.col1

  2. Но вам нужен хотя бы один из них.В противном случае у вас на руках будет декартово соединение: каждая строка из таблицы 1 будет присоединена к каждой строке в таблице 2.Если в table1 100 строк, а в table2 1000 строк, результирующий запрос вернет 100 000 результатов. 

    SELECT * FROM table1 t1,table2 t2 --warning!
0 голосов
/ 29 июня 2010

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

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

Причина, по которой я упоминаю об этом, заключается в том, что мы унаследовали унаследованное приложение для составления отчетов, которое имело именно эту конструкцию, в соответствии с: 

where id = id

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

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

Хорошо, представьте наше удивление на следующей итерации, когда база данных замедлилась до доли своей прежней скорости, когда пользователи выполняли специальные запросы к полю id: -)

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

Итак, я не говорю, что вы не можете сделать это, просто предполагаю, что было бы неплохо понять, почему это было сделано первым.

...