My<cod/>.net
SQL С Предохранительной Сеткой
В моей фирме есть талантливый и умный оперативный персонал, который очень много работает. Я хотел бы дать им инструмент SQL-execution, который поможет им избежать распространенных, легко обнаруживаемых ошибок SQL, которые легко сделать, когда они спешат. Может ли кто-нибудь предложить такой инструмент? Далее следуют подробности.
Часть компетенции оперативной группы заключается в написании очень сложных специальных запросов SQL. Неудивительно, что операторы иногда делают ошибки в запросах, которые они пишут, потому что они очень заняты.
К счастью, их запросы все SELECTs не изменяют данные SQL, и они все равно работают на копии базы данных. Тем не менее, мы хотели бы предотвратить ошибки в SQL, которые они запускают. Например, иногда ошибки приводят к длительным запросам, которые замедляют работу дублирующей системы, которую они используют, и причиняют неудобства другим, пока мы не найдем преступный запрос и не убьем его. Хуже того, иногда ошибки приводят к явно правильным ответам, которые мы не улавливаем до тех пор, пока много позже, с последующим смущением.
Наши разработчики также делают ошибки в сложном коде, который они пишут, но у них есть Eclipse и различные плагины (такие как FindBugs), которые ловят ошибки при вводе. Я бы хотел дать операторам нечто подобное - в идеале это было бы видно
SELECT U.NAME, C.NAME FROM USER U, COMPANY C WHERE U.NAME = 'ibell';
и перед тем, как вы его исполните, он скажет: "Эй, вы поняли, что это декартово произведение? Вы уверены, что хотите это сделать?"Это не должно быть очень умно - найти явно отсутствующие условия соединения и подобные очевидные ошибки было бы прекрасно.
Похоже, что TOAD должен сделать это, но я не могу найти ничего о такой функции. Существуют ли другие инструменты, такие как TOAD, которые могут обеспечить такое полуинтеллектуальное исправление ошибок?
Обновление: я забыл упомянуть, что мы используем MySQL.
Если ваши сотрудники используют программу mysql(1) для выполнения запросов, вы можете использовать опцию safe-updates (aka i-am-a-dummy), чтобы получить часть того, что вам нужно. Его название несколько вводит в заблуждение; он не только предотвращает UPDATE и DELETE без WHERE (о чем вы не беспокоитесь), но также добавляет неявные LIMIT 1000 к SELECT утверждениям и прерывает SELECTs, которые имеют соединения и, по оценкам, рассматривают более 1 000 000 кортежей-идеально подходит для предотвращения декартовых соединений.
...
"написание очень сложных специальных запросов SQL.... они так заняты"
Опасность Уилл Робинсон!
Автоматизировать Автоматизировать Автоматизировать.
В идеале, оперативная команда не должна быть поставлена в положение, когда ей приходится писать запросы на лету в условиях высокого стресса – это путь к катастрофе! Лучше для них создать библиотеку предварительно написанных сценариев, которые прошли соответствующее тестирование, чтобы убедиться, что он а) делает то, что вы хотите б) обеспечивает аудит trail c) имеет возможную функцию типа "отменить".
В противном случае, предоставление им пользователя ID, у которого есть только SELECT премий, может помочь :-)
Вы можете найти SQL подсказку от redgate полезной. Я не уверен, какой компонент database engine вы используете, так как он предназначен только для MSSQL сервера
Я не ожидал, что что-то подобное может существовать. Инструмент должен был бы сначала реализовать все, что реализует парсер SQL в вашей базе данных, а затем выполнить анализ модели данных для прогнозирования запросов "bad".
Лучше всего было бы написать плагин для текстового редактора, который выполнял бы базовую проверку подозрительных шаблонов и выделял их иначе, чем стандартный режим .sql. Но даже это было бы довольно трудно.
Я был бы счастлив с инструментом, который вызывал тревожные сигналы всякий раз, когда я вводил инструкцию update без предложения where. И, возможно, назначили легкий электрический шок, так как обычно это происходит около 1 часа ночи после долгого дня, когда случаются подобные ошибки.
Это было бы довольно легко построить, настроив образец базы данных с очень небольшим количеством фиктивных данных, которые будут получать запрос в первую очередь. Произойдет пара вещей:
- Вы можете получить синтаксическую ошибку SQL, которая не будет сильно загружать базу данных, так как это небольшая база данных.
- Вы можете получить ответ, который может быть четко показан, чтобы содержать каждую строку в одной или нескольких таблицах, что, вероятно, не то, что они хотят.
- Вещи, которые проходят вышеописанные условия, скорее всего, будут в порядке, поэтому вы можете запустить их против копии производственной базы данных.
Предполагая, что ваша схема не сильно меняется и не является особенно странной, написание вышеизложенного, вероятно, является самым быстрым решением вашей проблемы.
Я бы начал с некоторых стандартов кодирования - например, никогда не используйте тип соединения в вашем примере - это часто приводит к плохим результатам (особенно в SQL Server, если вы попытаетесь сделать внешнее соединение таким образом, вы получите плохие результаты). требуйте от них выполнения явных соединений.
Если у вас сложные отношения, вы можете поместить их в представления, а затем написать запросы adhoc из этих представлений. Тогда, по крайней мере, они никогда не совершат ошибку, получив неверные соединения.
Разве вы не можете просто ограничить время выполнения запроса? Я не уверен насчет MySQL, но для SQL сервера даже простой анализатор запросов по умолчанию может ограничить время выполнения запросов до истечения времени ожидания. Соедините это с ограниченными правами, чтобы они могли выполнять только запросы SELECT, и вы должны быть в значительной степени охвачены.