Что плохого в использовании SQL INNER JOIN

Каждый раз, когда отображается диаграмма базы данных, люди, которые критикуют, являются внутренними соединениями. Они смотрят на них тяжело и имеют вопросы, чтобы увидеть, действительно ли должно быть внутреннее соединение.Что плохого в использовании SQL INNER JOIN

Простая библиотека Пример:

многие-ко-многим, как правило, определяется в SQL с тремя таблицами: книги, Категория, BookCategory.

В этой ситуации, категория представляет собой таблицу, которая содержит два столбца: ID, CategoryName.

В этой ситуации у меня возникли вопросы о таблице Категория, она нужна? Может ли он использоваться в качестве справочной таблицы, а в таблице BookCategory следует хранить таблицу CategoryName вместо CategoryID, чтобы прекратить выполнение дополнительной INNER JOIN. (По этому вопросу мы будем игнорировать изменение, удаление каких-либо категорий)

Вопрос в том, что так плохо о внутренних соединениях? В какой момент они делают это негативно (общие рекомендации, такие как # транзакций, количество записей, количество объединений в заявлении и т. Д.)?

источник

2010-03-16 SBurris

ничего плохого о если вы используете их там, где они нужны .. на самом деле это очень позитивная вещь :) –

Я никогда не слышал никаких негативных высказываний о INNER JOIN. Можете ли вы опубликовать ссылку на нее? –

Я бы очень серьезно посмотрел на ** внешнее соединение ** заявление! Это потенциально убийцы производительности - конечно, не внутренние соединения ..... –

Ваш пример - хороший контрпример. Как вы переименовываете категории, если они распространяются по разным строкам таблицы BookCategory? Ваш UPDATE для переименования коснется всех строк той же категории.

С отдельной таблицей необходимо обновить только одну строку. Нет дублирующей информации.

источник

2010-03-16 00:44:54

+1 абсолютно - подведите итог красиво. –

Правильно, я понимаю, что обновление одной строки против многих в одной таблице было бы тривиальным, я хотел бы сохранить этот тип обсуждения из этого, хотел бы сосредоточить INNER JOIN. – SBurris

Я не уверен, что во внутреннем соединении есть что-то не так, как каждый, если вы добавляете в свой код воздействие на производительность (или я должен сказать каждую строку ...), но все же вам нужно минимум число тех, кто заработает вашу систему (да, я знаю о машинах Тьюринга). Итак, если у вас есть что-то, что не нужно, оно будет нахмуриться.

источник

2010-03-16 00:43:18

соединения фактически улучшают производительность (в большинстве случаев) ... посмотрите http://www.sql-server-performance.com/tips/tuning_joins_p1.aspx –

@Gaby Разделив связь на две части и объединив их снова при получении данных (почти), конечно, запрос будет медленнее. Хотя это сделает некоторые обновления быстрее. На связанных страницах вы узнаете, как повысить производительность соединения, но не сравнивайте модели с объединениями и без них. –

@ Даниэль, когда вы выбираете все, что я согласен с тем, что одна таблица будет самой быстрой, но когда вы начинаете вводить фильтры, я считаю, что объединенные таблицы будут работать быстрее, поскольку они будут проходить фильтрацию, сравнивая числа. Это просто мое понимание, и я не эксперт по этому вопросу. –

Я буду больше беспокоиться о присоединениях OUTER и о возможности получить информацию, которая не была предназначена.

В вашем примере, имея Category таблицы означает, что книга ограничена быть поданы в соответствии с заданной Category (через foriegn ключ), если вы просто оттолкнули несколько записей в к BookCategory таблице, то это будет сложнее лимит, который выбран для Category.

Выполнение соединения INNER не так уж плохо, для чего созданы базы данных. Единственный раз, когда это плохо, это когда вы делаете это на таблице или столбце, который недостаточно индексирован.

источник

2010-03-16 00:49:32 slugster

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

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

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

Кстати, почему вы (они) упоминаете только внутренние соединения? Как левые, правые и полные внешние соединения существенно отличаются от внутренних объединений?

источник

2010-03-16 00:59:53

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

В частности, INNER JOINs являются неэффективными или плохими ... JOINs являются центром реляционных БД, и они существуют уже много десятилетий. Это неправильно, когда вы используете это неправильно, потому что очевидно, что кто-то делает это правильно, так как он еще не вымер. Лично я предполагаю, что кто-то выбрасывает подобные заявления, либо не знает SQL, либо знает достаточно, чтобы попасть в беду. В следующий раз, когда это произойдет, научите их использовать кеш запросов.

(не упоминая обновление/удаление, но не сказал Вставки !: возросшую ремонтопригодность через избегая людей и их опечаток может легко стоить по крайней мере 10x время объединения займет.)

источник

2010-03-16 03:12:26 tadamson

Что плохого в использовании SQL INNER JOIN

ответ

Смежные вопросы