Разбор T-SQL для параметризации запроса
Приложение, над которым я сейчас работаю, генерирует множество встроенных запросов SQL. Затем весь сгенерированный SQL передается классу выполнения базы данных. Я хочу написать службу синтаксического анализа для класса выполнения данных, который будет принимать такой запрос:
SELECT field1, field2, field3 FROM tablename WHERE foo=1 AND bar = "baz"
и превратите это примерно так:
SELECT field1, field2, field3 FROM tablename WHERE foo=@p1 AND bar=@p2 blah blah blah
Что-нибудь, что уже написано, сделает это за меня на C# или vb.net? Это задумано как временный промежуток перед рефакторингом DAL для этого проекта.
Обновлено: Ребята, у меня есть огромное приложение, которое было перенесено с классического ASP на ASP.NET буквально с тысячами строк встроенного SQL. Единственное спасение - весь сгенерированный sql передается классу выполнения данных. Я хочу захватить sql перед выполнением и параметризовать их на лету в качестве остановки для переписывания всего приложения.
Ответы 6
Не делай этого. Это слишком много работы. Кроме того, такой подход сопряжен с множеством рисков для безопасности.
Изучите как минимум объекты Command и параметризованные запросы.
Я бы поддержал предложение использовать параметры команды, чтобы делать то, что вы хотите. Любой вид синтаксического анализа строки запроса SQL - это просто просьба, чтобы кто-то поиграл с вами в игру с SQL-инъекцией. Ниже приведен пример кода. Коллекцией параметров легко манипулировать обычным способом.
command.CommandText = "SELECT * FROM table WHERE key_field='?'"
command.Parameters.Append command.CreateParameter(, 8, , , "value") '8 is adBSTR value
set rsTemp = command.Execute
o думаю, что твоя задача слишком честна ... вам следует создать очень надежный парсер ... я думаю, что лучше и проще начать переписывать приложение, находить точки, в которых генерируются запросы, и проводить рефакторинг кода.
Хороший вид!
Я могу вспомнить только одно преимущество, которое может дать параметризация запросов на лету: это уменьшит текущую уязвимость вашего приложения к атакам с использованием SQL-инъекций. В любом другом случае лучшее, на что вы могли бы надеяться, - это то, что этот гипотетический оперативный синтаксический анализатор / интерпретатор ничего не сломает.
Даже если вам не приходилось писать такие вещи самостоятельно (и я уверен, что вы это делаете), это довольно значительный риск, который стоит ввести в производственную систему, тем более что это временная мера, которая будет отброшена при рефакторинге приложения. Достаточно ли высок риск атаки с использованием SQL-инъекции, чтобы это оправдать?
Вы не задумывались о том, чтобы запустить заменяющее регулярное выражение в старом коде? Что-то, что будет извлекать значения из текущих запросов, заменять их параметрами и добавлять после строки запроса вызов Command.Parameters.AddWithValue (paramName, paramValue), если все текущие встроенные SQL следуют одному и тому же значению (или если почти все они работают, а остальное вы можете исправить в своем любимом редакторе).
Выполните рефакторинг сейчас.
Вы обманываете себя, если думаете, что этот слой абстракции сможет появиться быстрее и проще. В глубине души вы знаете, что это увеличивает риск и неопределенность в проекте, но вы хотите убить проблему SQL-инъекций или любую другую проблему, с которой вы боретесь, с помощью волшебной пули.
Время, которое вы потратили бы на написание этой новой подсистемы синтаксического анализа и регрессионного тестирования системы, вы, вероятно, могли бы заменить весь встроенный код обращениями к относительно меньшему количеству генерируемых кодом и протестированных SP в вашей БД. К тому же вы можете делать это по частям.
Зачем создавать значительный кусок одноразового кода, который будет трудно отлаживать и который на самом деле не соответствует тому, как вы хотите, чтобы окончательная архитектура выглядела?
пожалуйста, прочтите весь вопрос, я пытаюсь параметризовать запросы, прежде чем они попадут в базу данных, без необходимости переписывать тысячи строк кода.