Лучший способ понять сложные операторы SQL?

Question

У кого-нибудь есть метод для понимания сложных операторов SQL? При чтении структурного / OO-кода обычно существуют уровни абстракции, которые помогают разбить его на управляемые куски. Однако часто в SQL кажется, что вам нужно отслеживать, что происходит в нескольких частях запроса одновременно.

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

Есть ли лучший способ разбить SQL-запрос на управляемые части?

Answer 1

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

Предположим, например, что у вас есть таблица для книг и таблица для цен. Таблица «Цены» может содержать несколько записей для каждой книги (поскольку цена может меняться).

Если вы хотите получить список текущих книг и цен, вы должны объединить две таблицы.

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

Как только вы освоитесь, сложные запросы станут проще для анализа.

Answer 2

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

Answer 3

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

В большинстве случаев ясность важнее производительности, а подзапросы легче отлаживать.

Кстати: почему вы используете непонятные псевдонимы таблиц?

Answer 4

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

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

Я фанатично всегда использую псевдонимы таблиц (например, CLIENT_HISTORY_ITEM T1) и круглые скобки вокруг критериев выражений. Я часто меняю номер псевдонима таблицы на десять или около того для каждой части запроса, чтобы я мог видеть, что происходит откуда:

ВЫБРАТЬ T1.ID ИЗ ТАБЛИЦЫ 1 T1 ГДЕ T1.DATE = (ВЫБЕРИТЕ МАКС. (T11.DATE) ИЗ ТАБЛИЦЫ 1 T11 ГДЕ (T1.AREA = T11.AREA))

Приветствия

Answer 5

Если вы используете PostgreSQL, для этого отлично подойдет инкапсуляция.

Answer 6

Использование CTE или производных таблиц (по крайней мере, в MS SQL) может быть полезным для форматирования оператора SQL без разделения его на отдельные запросы с использованием временных таблиц для их «объединения».

Я согласен с другими, что упомянутые запросы довольно просты.

Я смотрю на c # и удивляюсь, почему у вас так много строк, чтобы просто обработать несколько тысяч строк ...