понимание присоединиться

Question

понимание присоединиться

0

im, глядя на этот код:

select customers.name
from customers, orders, order_items, books
where customers.customerid = orders.customerid
and orders.orderid = order_items.orderid
and order_items.isbn = books.isbn
and books.title like '%java%';

и трудно понять его.

сначала у меня есть 4 таблицы, а код создает динамическую таблицу,
должен ли я смотреть на него по-другому, чтобы лучше понять его?

во-первых, im выбирая customer.name, но только после того, как последний код запущен, и у меня есть моя динамическая таблица, верно?

Должен ли я попытаться выровнять каждую 2 таблицы по строкам, используя динамическую таблицу, которая была сделана ранее?

а также во время создания таблицы записываются все данные из таблицы или только то, что я спрашиваю в том, где?

плохо оцените свою помощь.

Tal Pergricht 01 дек. 2010, в 22:26

Источник

Теги:

mysql

sql

join

2 ответа

Ещё вопросы

RabidFire · Answer 1 · 2010-12-01T18-29-00.000Z

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

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

Лучшим способом написания вышеприведенного утверждения будет следовать новый синтаксис:

SELECT customers.name FROM customers
INNER JOIN orders ON customers.customerid = orders.customerid
INNER JOIN order_items ON orders.orderid = order_items.orderid
INNER JOIN books ON order_items.isbn = books.isbn
WHERE books.title LIKE '%java%'

Подробнее читайте здесь по причинам.

Dragontamer5788 · Answer 2 · 2010-12-01T18-35-00.000Z

Rapid Fire проделала хорошую работу, объясняя аспект "кросс-продукта". Вот несколько дополнительных советов.

В первую очередь: SQL не является процедурным кодом. Его запрос. Весь запрос выполняется одновременно. Вам нужно прочитать весь запрос, чтобы понять все это. Нет никакого "порядка", в котором вы читаете запросы. Для аналогии X = Y совпадает с Y = X... аналогично, вы читаете весь запрос как единое целое.

Затем SQL абстрагирует вас от процесса создания таблицы. Подумайте об этом с математической точки зрения, основанной на реляционной алгебре. То есть, Таблицы - это отношения (или кортежи) и т.д. Посмотрите C. J. Дайте книги и прочитайте их. Существует математический язык, на котором был разработан SQL, и обучение, которое значительно улучшит вашу способность понимать базы данных.

Я думаю, что это утверждение может быть опасным для начинающих: «SQL - это не процедурный код. Это запрос. Весь запрос выполняется одновременно». Ничто не происходит одновременно, нам всем нужен хороший метод для чтения запроса, и каждый оптимизатор запросов будет применять «процедуру» для интерпретации вашего запроса и отправки его на выполнение. Из соображений производительности все эти вещи должны быть известны, ни один sql-сервер не является волшебным черным ящиком, в который вы можете выгружать данные и мгновенно извлекать их. </ Декламация> <извините>
@ceteras: Конечно, оптимизация важна, а понимание последовательности синтаксического анализа и оптимизации позволит вам создавать более эффективные запросы. Но у оригинального плаката есть проблемы с базовой семантикой, а именно: соединения. Это абсолютно важно, чтобы использовать SQL в любом случае. На данный момент более важно понимать SQL с точки зрения «черного ящика». После того, как он поймет это ... он может начать беспокоиться об оптимизации.