ОСТАВЛЕННОЕ СОЕДИНЕНИЕ по сравнению с несколькими операторами SELECT

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

Я с Вами - единственный SQL был бы лучше

Вы абсолютно корректны, что единый запрос является способом пойти. Для добавления некоторого значения к другим предлагаемым ответам позволяют мне добавить эту аксиому: "Используйте правильный инструмент для задания, Сервер базы данных должен обработать работу запросов, код должен обработать процедурную работу".

Ключевая идея позади этого понятия состоит в том, что компилятор/оптимизаторы запросов может сделать лучшее задание, если они знают всю проблемную область вместо половины из него.

Существует опасность рассматривать Ваш DBMS SQL, как будто это была файловая система ISAM, выбирающая из единственной таблицы за один раз. Это могло бы быть более чисто для использования единственного ВЫБОРА с помощью внешнего объединения. С другой стороны, обнаружение пустого указателя в коде приложения и решение, что сделать на основе пустого указателя по сравнению с непустым указателем, являются также не абсолютно чистыми.

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

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

При полагании, которые в одной базе данных совершают нападки, у Вас есть все данные, Вам нужно наличие одного единственного SQL-оператора, была бы лучшая производительность 99% времени. Не уверенный, если соединения создание динамично в этом случае или не, но раз так выполнение так, является дорогим. Даже если процесс при многократном использовании существующих соединений, которые не получает DBMS, оптимизирует запросы быть лучшим способом и не действительно использованием отношений.

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

Мне кажется, что то, что Вы говорите, довольно допустимо - почему исчерпывают два вызова к базе данных, когда каждый сделает - если обе записи не будут необходимы независимо как объекты (?)

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

Это было бы более хорошо читать как запрос:

Select a.blah1, a.blah2, b.something From foo a Left Join foo2 b On a.foreign_key = b.key Where a.Key = bar;

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

Да, я думаю, что походит на то, что Вы говорите, корректно.

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

У меня было два или три экземпляра теперь, где исходный запрос, который я наследовал, состоял из единого запроса, который имел, таким образом, много из участвует в нем, и SQL потребовалась бы хорошая минута для подготовки оператора.

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

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

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

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

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

Миф предотвращения соединений похож на высказывание, что мы должны постараться не писать циклы в нашем коде приложения, потому что выполнение строки кода многократно, очевидно, медленнее, чем выполнение его однажды. Ничего не сказать относительно "издержек" ++i и тестирование i<20 во время каждого повторения!

Единственный SQL-запрос ввел бы больше представления в качестве SQL-сервера (Который иногда не совместно использует то же местоположение), просто должен обработать один запрос, если Вы использовали бы несколько SQL-запросов затем, Вы представляете много издержек:

Выполнение большего количества инструкций ЦП, отправка второго запроса к серверу, создают второй поток на сервере, выполняют возможный больше инструкций ЦП относительно разъединения, уничтожают второй поток на сервере, передают вторые результаты обратно.

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

Выполнение простых двух соединений таблицы обычно является лучшим способом следить за этой проблемной областью, однако в зависимости от состояния таблиц и индексации, существуют определенные случаи, где может быть лучше сделать два избранных оператора, но обычно я не столкнулся с этой проблемой, пока я не начал приближаться к 3-5 объединяемым таблицам, не всего 2.

Просто удостоверьтесь, что у Вас есть закрывающие индексы на обеих таблицах, чтобы гарантировать, что Вы не сканируете диск для всех записей, который является самой большой производительностью, совершает нападки, база данных добирается (в моем ограниченном опыте)

Необходимо всегда пытаться минимизировать количество запроса к базе данных, когда Вы можете. Ваш пример идеально подходит только для 1 запроса. Таким образом, Вы сможете позже кэшироваться более легко или обработать больше запроса в то же время, потому что вместо того, чтобы всегда использовать запрос 2-3, которые требуют связи, Вы будете иметь только 1 каждый раз.