SQL-соединение: где предложение по сравнению с предложением

В Android вы не можете конкатенировать строки внутри xml

Ниже не поддерживается

@string/string1 TEST

Проверьте эту ссылку ниже, чтобы узнать, как ее достичь

Как конкатенировать несколько строк в android XML?

595
задан Community 23 May 2017 в 10:31
поделиться

6 ответов

Они не то же самое.

Рассматривают эти запросы:

SELECT *
FROM Orders
LEFT JOIN OrderLines ON OrderLines.OrderID=Orders.ID
WHERE Orders.ID = 12345

и

SELECT *
FROM Orders
LEFT JOIN OrderLines ON OrderLines.OrderID=Orders.ID 
    AND Orders.ID = 12345

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

С INNER JOIN, пункты эффективно эквивалентны. Однако просто, потому что они - функционально то же, в этом они приводят к тем же результатам, не означает, что два вида пунктов имеют то же семантическое значение.

771
ответ дан Joel Coehoorn 23 May 2017 в 10:31
поделиться

С точки зрения оптимизатора это не должно иметь значения, определяете ли Вы свои пункты соединения с НА или ГДЕ.

Однако, по моему скромному мнению, я думаю, что это намного более ясно использовать НА пункте при выполнении соединений. Тем путем у Вас есть определенный раздел Вас запрос, который диктует, как соединение обрабатывается по сравнению со смешанным с остальной частью операторов Where.

8
ответ дан Grant Limberg 23 May 2017 в 10:31
поделиться

На внутреннем объединении они имеют в виду то же самое. Однако Вы получите различные результаты во внешнем объединении в зависимости от того, если Вы вставите условие объединения ГДЕ по сравнению с НА пункте. Смотрите на этот связанный вопрос и этот ответ (мной).

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

30
ответ дан Community 23 May 2017 в 10:31
поделиться

Путем я делаю это:

  • Всегда помещает условия объединения в ON пункт, если Вы делаете INNER JOIN. Так, не добавляйте никого, КУДА условия к НА пункте, поместите их в WHERE пункт.

  • , Если Вы делаете LEFT JOIN, добавьте любого ГДЕ условия к ON пункт для таблицы в право сторона соединения. Это - необходимость, потому что добавление оператора Where, который ссылается на правую сторону соединения, преобразует соединение во ВНУТРЕННЕЕ ОБЪЕДИНЕНИЕ.

    исключение - при поиске записей, которые не находятся в конкретной таблице. Вы добавили бы ссылку на уникальный идентификатор (который никогда не является ПУСТЫМ) в ПРАВИЛЬНОЙ Объединяющей таблице к оператору Where этот путь: WHERE t2.idfield IS NULL. Так, единственное время, необходимо сослаться на таблицу на правой стороне соединения, должно найти те записи, которые не находятся в таблице.

41
ответ дан Marc.2377 23 May 2017 в 10:31
поделиться

На INNER JOIN с они являются взаимозаменяемыми, и оптимизатор перестроит их по желанию.

На OUTER JOIN с, они являются не обязательно взаимозаменяемыми, в зависимости от которой стороны соединения они зависят от.

я положил их на любое место в зависимости от удобочитаемости.

140
ответ дан Cade Roux 23 May 2017 в 10:31
поделиться

это мое решение.

SELECT song_ID,songs.fullname, singers.fullname
FROM music JOIN songs ON songs.ID = music.song_ID  
JOIN singers ON singers.ID = music.singer_ID
GROUP BY songs.fullname

У вас должна быть группа GROUP BY , чтобы заставить ее работать.

Надеюсь на эту помощь.

-5
ответ дан 22 November 2019 в 21:58
поделиться
Другие вопросы по тегам:

Похожие вопросы: