Убедитесь, что только «разумные» запросы

Question

В нашей организации нам нужно разрешить сотрудникам фильтровать данные в нашем веб-приложении, предоставляя предложения WHERE. Он долго работал, но мы иногда сталкиваемся с пользователями, которые предоставляют запросы, требующие полного сканирования таблиц на больших таблицах или неэффективных объединений и т. Д.

Какой-то клоун может написать что-то вроде:

select * from big_table where
Name in (select name from some_table where name like '%search everything%')
or name in ('a', 'b', 'c')
or price < 20
or price > 40
or exists (select 1 from some_other_table where col1 + col2 + col3 = 4)
or exists (select 1 from table_a, table+b)

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

Но для пользователя это может иметь смысл.

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

Я предполагаю, что на c # / sql-server это программный способ получить план выполнения запроса перед его выполнением. И если да, то какие факторы влияют на стоимость? Предполагаемая стоимость ввода / вывода? Ориентировочная стоимость процессора? Каковы разумные пределы, при которых пользователь может сказать, что его запрос бесполезен?

РЕДАКТИРОВАТЬ: Мы компания по исследованию рынка. У нас есть тысячи опросов, каждый со своими данными. У нас есть десятки исследователей, которые хотят разрезать эти данные произвольным образом. У нас есть инструменты, позволяющие им создавать «действительные» фильтры с использованием графического интерфейса, но некоторые «опытные пользователи» хотят предоставлять свои собственные запросы. Я понимаю, что это не стандартная или лучшая практика, но как еще я могу позволить десяткам пользователей запрашивать таблицы для строк, которые они хотят, используя произвольно сложные условия и постоянно меняющиеся условия?

Answer 1

Предпосылка вашего вопроса гласит:

В нашей организации нам необходимо разрешить сотрудникам фильтровать дату в нашем веб-приложении, предоставляя предложения WHERE.

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

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

Однако, если ваши пользователи действительно достаточно опытны (и заслуживают доверия!), Чтобы напрямую предоставлять предложения WHERE, им нужно знать, что они могут и не могут представить в качестве фильтра.

Answer 2

Вы можете попробовать использовать следующее:

SET SHOWPLAN_ALL ON
GO
SET FMTONLY ON
GO
<<< Your SQL code here >>>
GO
SET FMTONLY OFF
GO
SET SHOWPLAN_ALL OFF
GO

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

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

Answer 3

В дополнение к попытке контролировать то, что пользователи вводят (что является проигрышной битвой, всегда будет новый найм, который придет с неординарным запросом), я бы посмотрел на Resource Governor, см. Управление Рабочие нагрузки SQL Server с регулятором ресурсов . Вы помещаете специальные запросы в отдельный пул и ограничиваете выделенные ресурсы. Таким образом, вы можете смягчить проблему, ограничив размер ущерба, который может нанести неправильный запрос, до других задач.

И вам также следует рассмотреть возможность предоставления доступа к данным другими способами, например Power Pivot , и позволить пользователям массировать свои данные так сильно, как они хотят, в своем собственном Excel. Опытные пользователи бизнеса любят это, и влияние на Transaciton Processign Server минимально.

Answer 4

Если у вас так много данных, и вы хотите предоставить своим клиентам возможность анализировать и просматривать информацию так, как они хотят, я настоятельно рекомендую рассказать о OLAP технологиях..

Answer 5

Я работал в нескольких местах, где это также возникло. В конечном итоге мы НЕ предоставляли пользователям неограниченный доступ и обещали, чтобы ИТ-специалисты делали все возможное для предоставления запросов при необходимости. Проблема заключалась в том, что база данных была довольно сложной, и даже если пользователи могли писать грамматически и синтаксически правильный SQL, они не обязательно понимали отношения между таблицами. Другими словами, даже если бы они могли написать собственный SQL, они бы получили неправильные ответы. Мы убедили пользователей в том, что риск принятия неправильного решения на основе ошибочного или неполного понимания 200 таблиц в базе данных был слишком высок. Лучше сразу получить правильный ответ, чем неправильный.

Другая часть этого заключается в том, что делает ИТ, когда пользователь A пишет запрос и получает 1 ответ, а затем пользователь B пишет то, что он считает тем же запросом, и получает другой ответ? Это работа ИТ, чтобы найти различия? Чтобы исправить обе части SQL? и т.д. Суть в том, что я не позволю им доступ. Я бы загружал систему предопределенными запросами, как уже упоминали другие, и пытался обучить mgmt, почему это единственный способ, которым она будет работать в долгосрочной перспективе.

Answer 6

Вы можете создать модель данных для своей базы данных и позволить пользователям использовать построитель отчетов служб отчетов SQL. Он основан на графическом интерфейсе и не требует написания предложений WHERE, поэтому должен быть предел того, какой ущерб они могут нанести.

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

Answer 7

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

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

Answer 8

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

Answer 9

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

Может быть, вам следует скопировать данные, которые необходимо запросить ad-hoc, в отдельную базу данных, чтобы изолировать любые проблемы от большинства пользователей.

Answer 10

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

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

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

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