Есть ли такая вещь, как запрос слишком большой?

Question

У меня нет большого опыта работы с SQL. Большинство запросов, которые я написал, были очень маленькими. Всякий раз, когда я вижу очень большой запрос, я всегда предполагаю, что его нужно оптимизировать. Но так ли это? или есть ситуации, когда нужны действительно большие запросы?

Кстати, когда я говорю большие запросы, я имею в виду запросы, которые превышают 1000+ символов

Answer 1

Да, любой оператор, метод или даже запрос могут быть "слишком большими".

Проблема в том, чтобы определить, что слишком большое на самом деле.

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

Мне всегда нравится смотреть на вещи с точки зрения обслуживания. Если запрос сейчас трудно понять, что, если вам придется что-то отлаживать в нем?

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

Answer 2

Как и в других языках, вы не можете определить эффективность запроса на основе количества символов. Кроме того, 1000 символов - это не то, что я мог бы назвать «большими», особенно когда вы используете хорошие имена таблиц / столбцов, псевдонимы, которые имеют смысл, и т. Д.

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

Мое эмпирическое правило таково: пишите самый лучший, самый трудный, самый простой код, который вы можете, и оптимизируйте, где это необходимо - то есть, где вы видите узкое место в производительности или где (как это часто бывает) вы бьете себя в голову и скажи "D'OH!" около трех часов утра в отпуске.

Резюме: хорошо кодируйте и оптимизируйте при необходимости.

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

Answer 3

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

Когда я вижу сложный запрос, моя первая мысль - возвращает ли он то, что разработчик действительно намеревался вернуть (вы будете удивлены, как часто ответ на этот вопрос нет), а затем я смотрю, чтобы увидеть, может ли производительность настроена. Да, есть много плохо написанных длинных запросов, но есть также много или больше, которые делают то, что они должны делать, с такой скоростью, с какой это можно сделать без значительного изменения базы данных или более быстрого оборудования.

Answer 4

Количество символов не означает, что запрос должен быть оптимизирован - это то, что вы видите в тех символах, которые делают.

Такие вещи, как подзапросы поверх подзапросов, я бы рассмотрел. Я бы также рассмотрел СОЕДИНЕНИЯ, но это не займет много времени по сравнению с ERD, чтобы узнать, есть ли ненужное СОЕДИНЕНИЕ - первое, на что я посмотрю, будет то, какие таблицы объединены, но не используются в выводе, что хорошо, если таблицы являются таблицами типа link / corrollary / etc.

Answer 5

Где я работаю, мы создали хранимые процедуры, которые превышают 1000 символов. Я не могу сказать, что это НЕОБХОДИМО, но иногда спешка выигрывает у эффективности (особенно когда клиенту требуется быстрое исправление).

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

Answer 6

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

Я бы свел это к:

• Какова цель запроса?
• используется ли логика на основе множеств?
• повторно использовать какие-либо компоненты?
• это НЕПРАВИЛЬНО / НЕДОСТУПНО?
• каковы показатели производительности?
• проблемы с обслуживаемостью - написано ли это так, что другой разработчик может уклониться от своих намерений?