Внутреннее объединение, по сравнению с Где
Для этой цели вам понадобятся семафоры.
//Create the semaphore with count equal to the number of requests that will be made.
let semaphore = dispatch_semaphore_create(locationsArray.count)
for key in locationsArray {
let ref = Firebase(url: "http://myfirebase.com/" + "\(key.0)")
ref.observeSingleEventOfType(.Value, withBlock: { snapshot in
datesArray["\(key.0)"] = snapshot.value
//For each request completed, signal the semaphore
dispatch_semaphore_signal(semaphore)
})
}
//Wait on the semaphore until all requests are completed
let timeoutLengthInNanoSeconds: Int64 = 10000000000 //Adjust the timeout to suit your case
let timeout = dispatch_time(DISPATCH_TIME_NOW, timeoutLengthInNanoSeconds)
dispatch_semaphore_wait(semaphore, timeout)
//When you reach here all request would have been completed or timeout would have occurred.
13 ответов
Нет! Тот же план выполнения, посмотрите на эти две таблицы:
CREATE TABLE table1 (
id INT,
name VARCHAR(20)
);
CREATE TABLE table2 (
id INT,
name VARCHAR(20)
);
план выполнения относительно запроса с помощью внутреннего объединения:
-- with inner join
EXPLAIN PLAN FOR
SELECT * FROM table1 t1
INNER JOIN table2 t2 ON t1.id = t2.id;
SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);
-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2
И план выполнения относительно запроса с помощью оператора Where.
-- with where clause
EXPLAIN PLAN FOR
SELECT * FROM table1 t1, table2 t2
WHERE t1.id = t2.id;
SELECT *
FROM TABLE (DBMS_XPLAN.DISPLAY);
-- 0 select statement
-- 1 hash join (access("T1"."ID"="T2"."ID"))
-- 2 table access full table1
-- 3 table access full table2
Это верно, что, функционально, оба запроса должны быть обработаны тот же путь. Однако опыт показал, что, если Вы выбираете из представлений, которые используют новый синтаксис соединения, важно структурировать Ваши запросы с помощью него также. Оптимизатор Oracle может запутаться, если представление использует оператор "соединения", но запрос, получающий доступ к представлению, использует традиционный метод участия "где" пункт.
Они - оба внутренние объединения, которые делают то же самое, каждый просто использует более новый синтаксис ANSI.
Функционально они совпадают с, был сказан. Я соглашаюсь, хотя то выполнение соединения лучше для описания точно, что Вы хотите сделать. Много времен, я думал, что знал, как я хотел запросить что-то, пока я не начал делать соединения и понял, что хотел сделать различный запрос, чем исходный в моей голове.
В PostgreSQL нет определенно никакого различия - они оба приравниваются к тому же плану запросов. Я на 99% уверен, что это также имеет место для Oracle.
Они логически идентичны, но в более ранних версиях Oracle, которая приняла синтаксис ANSI часто были ошибки с ним в более сложных случаях, таким образом, Вы будете иногда встречаться с сопротивлением от разработчиков Oracle при использовании его.
Производительность должна быть идентичной, но я предложил бы использовать версию соединения из-за улучшенной ясности когда дело доходит до внешних объединений.
Также неумышленные декартовы произведения могут избегаться использования версия соединения.
эффект трети А является более легким для чтения SQL с более простым ГДЕ-УСЛОВИЕМ.
Используя JOIN делает код легче читать, так как это очевидно.
нет никакого различия в скорости (, я только что протестировал ее ), и план выполнения является тем же.
Я не знаю о Oracle, но я знаю, что старый синтаксис удерживается от использования в SQL Server и исчезнет в конечном счете. Прежде чем я использовал тот старый синтаксис в новом запросе, я проверю то, что Oracle планирует сделать с ним.
я предпочитаю более новый синтаксис, а не смешивание критериев соединения с другим необходимым где условия. В более новом синтаксисе намного более ясно, что создает соединение и что применяются другие условия. Едва ли большая проблема в коротком запросе как это, но это становится намного более сбивающим с толку, когда у Вас есть более сложный запрос. Так как люди учатся на основных запросах, я был бы склонен предпочитать, чтобы люди учились использовать синтаксис соединения, прежде чем им будет нужен он в сложном запросе.
И снова я не знаю Oracle а именно, но я знаю, что версия SQL Server старого стиля, оставленного соединение, испорчена даже в SQL Server 2000 и дает непоследовательные результаты (иногда левое соединение иногда перекрестное объединение), таким образом, это никогда не должно использоваться. Надо надеяться, Oracle не переносит ту же проблему, но конечно левые и правые соединения могут быть mcuh тяжелее для надлежащего выражения в старом синтаксисе.
Плюс он был мой опыт (и конечно это - строго личное мнение, у Вас может быть опыт differnt), что разработчики, которые используют стандартные соединения ANSII, склонны иметь лучшее понимание того, что соединение и что это означает с точки зрения вытаскивания данных из базы данных. Я живо, который является becasue большинство людей с хорошим пониманием базы данных, склонен писать более сложные запросы, и те, кажется, мне намного легче поддержать использование Стандарта ANSII, чем старый стиль.
Если оптимизатор запросов делает свое задание правильно, не должно быть никакого различия между теми запросами. Они - всего два способа определить тот же желаемый результат.
Они должны быть точно тем же. Однако как практика кодирования, я видел бы Соединение. Это ясно ясно формулирует Ваше намерение,
Не забывайте, что в Oracle, при условии, что атрибуты ключа соединения названы одинаково в обеих таблицах, вы также можете записать это как:
select *
from Table1 inner join Table2 using (ID);
Конечно, у него также есть тот же план запроса.
[Для бонусного балла ...]
Использование синтаксиса JOIN позволяет вам более легко закомментировать объединение, так как все оно размещается в одной строке. Этот может быть полезен, если вы отлаживаете сложный запрос
. Как говорят все, они функционально такие же, однако JOIN более четко выражает намерение. Поэтому он может помочь оптимизатору запросов либо в текущих версиях Oracle в определенных случаях (я понятия не имею, есть ли это), он может помочь оптимизатору запросов в будущих версиях Oracle (нет - у кого-то есть идеи), или может помочь, если вы смените поставщика базы данных.