ВНУТРЕННЕЕ ПРИСОЕДИНЕНИЕ НА ПУТЬ К ГДЕ
Проверить этот Пример
Html:
1
2
3
4
Javascript:
$('#showall').click(function(){
$('div').show();
});
$('#showdiv1').click(function(){
$('div[id^=div]').hide();
$('#div1').show();
});
$('#showdiv2').click(function(){
$('div[id^=div]').hide();
$('#div2').show();
});
$('#showdiv3').click(function(){
$('div[id^=div]').hide();
$('#div3').show();
});
$('#showdiv4').click(function(){
$('div[id^=div]').hide();
$('#div4').show();
});
10 ответов
INNER JOIN - это синтаксис ANSI, который вам следует используйте.
Обычно его считают более читабельным, особенно когда вы объединяете множество таблиц.
Его также можно легко заменить на OUTER JOIN всякий раз, когда возникает необходимость.
] WHERE синтаксис более ориентирован на реляционную модель.
Результат двух таблиц JOIN ed - это декартово произведение таблиц, к которым применяется фильтр, который выбирает только те строки, которые соответствуют соединяющимся столбцам. .
Это 'Это легче увидеть с помощью синтаксиса WHERE .
Что касается вашего примера, в MySQL (и в целом в SQL) эти два запроса являются синонимами.
Также обратите внимание, что MySQL также имеет ] Предложение STRAIGHT_JOIN .
Используя это предложение, вы можете управлять порядком JOIN : какая таблица сканируется во внешнем цикле, а какая - во внутреннем.
Вы не можете контролировать это в MySQL с использованием синтаксиса WHERE .
Вы не можете контролировать это в MySQL, используя синтаксис WHERE .
Вы не можете контролировать это в MySQL, используя синтаксис WHERE .
Другие отмечали, что INNER JOIN способствует удобочитаемости, и это главный приоритет; Я согласен. Позвольте мне попытаться объяснить , почему синтаксис соединения более читабелен.
Базовый запрос SELECT таков:
SELECT stuff
FROM tables
WHERE conditions
Предложение SELECT сообщает нам , что мы возвращаем; предложение FROM сообщает нам , откуда мы его получаем, а предложение WHERE сообщает нам , какие мы получаем.
JOIN - это утверждение о таблицах, как они связаны вместе (фактически, концептуально в единую таблицу). Любые элементы запроса, которые управляют таблицами - откуда мы получаем информацию - семантически принадлежат предложению FROM (и, конечно же, туда идут элементы JOIN). Помещение соединяемых элементов в предложение WHERE объединяет which и where-from ; поэтому предпочтительнее использовать синтаксис JOIN.
Синтаксис неявного соединения ANSI старше, менее очевиден и не рекомендуется.
Кроме того, реляционная алгебра допускает взаимозаменяемость предикатов в WHERE ] и INNER JOIN , поэтому даже запросы INNER JOIN с предложениями WHERE могут иметь предикаты, переупорядоченные оптимизатором.
Я рекомендую вам написать запросы в наиболее удобочитаемом виде.
Иногда это включает в себя выполнение INNER JOIN относительно «неполным»
Неявные соединения (так известен ваш первый запрос) становятся намного более запутанными, их трудно читать и трудно поддерживать, когда вам нужно начать добавлять больше таблицы по вашему запросу. Представьте, что вы выполняете тот же запрос и тип соединения для четырех или пяти разных таблиц ... это кошмар.
Использование явного соединения (ваш второй пример) намного удобнее и проще в обслуживании.
Я также отмечу, что использование старого синтаксиса более подвержено ошибкам. Если вы используете внутренние объединения без предложения ON, вы получите синтаксическую ошибку. Если вы воспользуетесь старым синтаксисом и забудете одно из условий соединения в предложении where, вы получите перекрестное соединение. Разработчики часто исправляют это, добавляя ключевое слово own (вместо того, чтобы исправлять соединение, потому что они все еще не понимают, что само соединение нарушено), что может решить проблему, но значительно замедлит запрос.
Дополнительно для техническое обслуживание, если у вас есть перекрестное соединение в старом синтаксисе, как сопровождающий узнает, собирались ли вы его создать (бывают ситуации, когда перекрестные соединения необходимы) или это была авария, которую следует исправить?
Позвольте мне указать ответьте на этот вопрос, чтобы понять, почему неявный синтаксис плох при использовании левых соединений. Sybase * = стандарту Ansi с 2 разными внешними таблицами для одной и той же внутренней таблицы
Плюс (здесь личная разглагольствования) стандарту, использующему явные объединения, более 20 лет, что означает, что синтаксис неявного объединения устарел для тех 20 лет. Вы бы написали код приложения, используя синтаксис, который устарел уже 20 лет? Почему вы хотите писать код базы данных?
Они имеют другое значение, удобочитаемое человеком.
Однако, в зависимости от оптимизатора запросов, они могут иметь одинаковое значение для машины.
Вы всегда должны кодировать так, чтобы они были удобочитаемыми. .
То есть, если это встроенная связь, используйте явное соединение. если вы сопоставляете слабо связанные данные, используйте предложение where.
Синтаксис соединения ANSI определенно более переносимый.
Я прохожу обновление Microsoft SQL Server, и я бы также упомянул, что синтаксис = * и * = для внешних соединений в SQL Server не поддерживается (без режима совместимости) для SQL Server 2005 и более поздних версий.
Я знаю, что вы говорите о MySQL, но в любом случае: В Oracle 9 явные и неявные соединения генерируют разные планы выполнения. AFAIK, который был решен в Oracle 10+: такой разницы больше нет.
Стандарт SQL: 2003 изменил некоторые правила приоритета, поэтому оператор JOIN имеет приоритет над соединением "запятая". Это может фактически изменить результаты вашего запроса в зависимости от того, как он настроен. Это вызывает некоторые проблемы у некоторых людей, когда MySQL 5.0.12 переходит на соблюдение стандарта.
Итак, в вашем примере ваши запросы будут работать так же. Но если вы добавили третью таблицу: SELECT ... FROM table1, table2 JOIN table3 ON ... WHERE ...
До MySQL 5.0.12, table1 и table2 объединялись первыми, затем table3. Теперь (5.0.12 и далее) сначала соединяются table2 и table3, затем table1. Это не всегда меняет результаты, но может, и вы можете даже не осознавать этого.
Я больше никогда не использую синтаксис «запятая», выбирая ваш второй пример. В любом случае это намного более читабельно, условия JOIN связаны с JOIN, а не разделены в отдельный раздел запроса.
Применение условных операторов в ON / WHERE
Здесь я объяснил шаги по обработке логических запросов.
Ссылка: Inside Microsoft® SQL Server™ 2005 T-SQL Querying
Издатель: Microsoft Press
Pub Date: 07 марта 2006 г.
Печать ISBN-10: 0-7356-2313-9
.
Печать ИСБН-13: 978-0-7356-2313-2
Страницы: 640
Внутри Microsoft® SQL Server™ 2005 T-SQL Querying
(8) SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1) FROM <left_table>
(3) <join_type> JOIN <right_table>
(2) ON <join_condition>
(4) WHERE <where_condition>
(5) GROUP BY <group_by_list>
(6) WITH {CUBE | ROLLUP}
(7) HAVING <having_condition>
(10) ORDER BY <order_by_list>
Первым заметным аспектом SQL, отличающимся от других языков программирования, является порядок обработки кода. В большинстве языков программирования код обрабатывается в том порядке, в котором он написан. В SQL, первое выражение, которое обрабатывается - это выражение FROM, в то время как выражение SELECT, которое появляется первым, обрабатывается почти последним.
Каждый шаг генерирует виртуальную таблицу, которая используется в качестве входа на следующем шаге. Эти виртуальные таблицы недоступны вызывающему абоненту (клиентскому приложению или внешнему запросу). Звонящему возвращается только таблица, сгенерированная на последнем шаге. Если в запросе не указан определенный пункт, то соответствующий шаг просто пропускается.
Краткое описание логических этапов обработки запроса
Не волнуйтесь, если описание этих этапов пока не имеет особого смысла. Они приведены в качестве справочной информации. Разделы, которые следуют за примером сценария, будут более подробно освещать эти шаги.
FROM: Декартовый продукт (перекрестное соединение) выполняется между первыми двумя таблицами в пункте FROM, в результате чего генерируется виртуальная таблица VT1.
ON: Фильтр ON применяется к VT1. В VT2 вставляются только те строки, для которых условие
OUTER (join): Если указан ВНЕШНИЙ JOIN (в отличие от CROSS JOIN или INNER JOIN), то строки из сохраненной таблицы или таблиц, для которых не было найдено совпадение, добавляются в строки из VT2 в качестве внешних строк, генерируя VT3. Если в пункте FROM появляется более двух таблиц, то шаги с 1 по 3 применяются повторно между результатом последнего соединения и следующей таблицей в пункте FROM до тех пор, пока не будут обработаны все таблицы.
ГДЕ: Фильтр ГДЕ применяется к VT3. В VT4 вставляются только те строки, для которых условие
<где_условие>является TRUE.GROUP BY: Строки из VT4 организованы в группы на основе списка столбцов, указанного в пункте GROUP BY. Генерируется VT5.
CUBE | ROLLUP: Супергруппы (группы групп) добавляются в строки из VT5, генерируя VT6.
HAVING: фильтр HAVING применяется к VT6. В VT7 вставляются только те группы, для которых условие
SELECT: Обрабатывается список SELECT, генерирующий VT8.
DISTINCT: Дублирующие строки удаляются из VT8. Генерируется VT9.
ORDER BY: Строки из VT9 сортируются в соответствии со списком столбцов, указанным в пункте ORDER BY. Генерируется курсор (VC10)
TOP: Указанное количество или процент строк выбирается с начала VC10. Генерируется таблица VT11, которая возвращается вызывающему абоненту.
Следовательно, при включении (INNER JOIN) данные будут отфильтрованы (количество данных в VT здесь будет уменьшено само по себе) перед применением пункта WHERE. Последующие условия соединения будут выполняться с отфильтрованными данными, что улучшает производительность. После этого условия фильтрации будут применяться только при условии "ГДЕ".
(Применение условных операторов в ON / WHERE в редких случаях не будет иметь особого значения. Это зависит от количества объединенных таблиц и количества строк, доступных в каждой объединенной таблице)
.