Вы бы отправили этот простой SQL обратно на доработку?

Question

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

Веб-страница динамически создает SQL для выполнения на основе введенных параметров. Например, если пользователь вводит «1» для «Бизнес-единицы», мы создаем SQL-код следующим образом:

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = '1'
--AND other criteria based on the input params

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

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%'
--AND other criteria based on the input params

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

Если это неуместный вопрос, потому что это не прямой код Q, дайте мне знать, и я немедленно удалю его. Меня очень смущает, разрешены ли такие субъективные вопросы или нет! Я буду следить за вашими ответами.

ти

---

Обновление:

Я использую базу данных Oracle.

У меня сложилось впечатление, что Oracle не оптимизирует "LIKE '%'", удаляя условие и оставляя его менее эффективным. Может ли кто-нибудь подтвердить?

Answer 1

Два запроса совершенно разные (с точки зрения набора результатов)

SELECT * FROM FACT;

и

SELECT * FROM FACT WHERE  
BUSINESS_UNIT LIKE '%';

Первый вернет все строки, второй, еслиесть значения NULL, эти строки не будут возвращены, потому что все, что сравнивается с NULL, равно NULL и, следовательно, не соответствует предикату.Вот как это будет работать в Oracle.

Answer 2

Хотя это выглядит крайне неэффективно, я только что протестировал его в SQL Server, и оптимизатор запросов был достаточно умен, чтобы отфильтровать его.

Другими словами,

SELECT * FROM FACT WHERE 
BUSINESS_UNIT LIKE '%'

и

SELECT * FROM FACT

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

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

Answer 3

SELECT * - красный флаг. Укажите список столбцов для запроса.

Answer 4

Этот запрос с BUSINESS_UNIT LIKE '%' не выглядит достаточно эффективным - я полагаю, что он заставит полностью просмотреть таблицу ...

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

Answer 5

Я бы спросил, почему переменные связывания не используются (если в особых случаях нет веских причин):

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = '1'

Почему это не так:

SELECT * FROM FACT WHERE 
BUSINESS_UNIT = :bu

Answer 6

Автор хотел иметь фиктивное утверждение, чтобы он / она мог добавлять «и» ко всем последующим утверждениям. поменять его на более качественное «неоперативное» выражение, например 1 == 1, поможет. Или они могли бы сделать немного больше работы и разумно вставить «где».

Answer 7

Я бы отправил его обратно, и мне нравится вопрос.

Все проверки кода в некоторой степени субъективны. Критерии должны основываться на ряде факторов.

• Работает ли это.

• Соответствует ли оно разумным ожиданиям в отношении производительности, удобства обслуживания, удобства использования и масштабируемости

Хотя я не тестировал эту конкретную конструкцию - я подозреваю (как и вы), что этот код будет делать ужасные вещи с вашим сервером SQL. Таким образом, производительность и масштабируемость ставятся под сомнение.