SQL: несколько запросов против объединений (конкретный случай) - PullRequest
1 голос
/ 09 февраля 2011

Этот вопрос, кажется, задавался много, и ответ, кажется, "это зависит от деталей".поэтому я спрашиваю о моем конкретном случае: лучше ли мне иметь несколько запросов или использовать объединения?

Подробности следующие:

  • таблица "products" - возможнооколо 2000 строк, около 15 столбцов
  • таблица «тегов» - вероятно, около 10 строк, 3 столбца
  • таблица «типов» - вероятно, около 10 строк, 3 столбца

Мне нужна таблица "tags" и "types", чтобы получить идентификатор tag / type, который находится в таблице продукта.

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

Мысли?

Ответы [ 5 ]

3 голосов
/ 09 февраля 2011

Спросите себя, какая дополнительная работа потребовалась бы для выполнения нескольких запросов ... Я не знаю, для чего вам нужны эти данные, но я предполагаю, что в какой-то момент вам нужно будет сопоставить результаты - сопоставить теги и типы к продуктам, не так ли? Если вы не делаете это с помощью объединения, вам просто нужно сделать это где-нибудь еще с помощью другого механизма.

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

Оставьте проблему создания набора результатов из ~ 2000 * 10 * 10 записей, а затем фильтрации его в базе данных, по моему мнению - это то, к чему это хорошо . :)

3 голосов
/ 09 февраля 2011

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

1 голос
/ 09 февраля 2011

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

Соединения, в частности, могут не понадобиться, EXISTS или IN могут использоваться, если вспомогательные таблицы не предоставляют столбцы в наборе результатов. СОЕДИНЕНИЕ между таблицами parent и child, и для родительского элемента может быть более одного дочернего элемента, приведет к увеличению числа искомых строк - не обязательно возвращаемых строк.

0 голосов
/ 09 февраля 2011

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

0 голосов
/ 09 февраля 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...