Сразу хочу извиниться перед коллегами, за быть может не очень корректный заголовок.
Итак к делу:
Коллеги, нужно автоматизировать SQL запрсы следующим образом:
Прикладной программист пишет:
-- запрос АSelect Orders.Customers.Address,
Orders.Customers.City,
Orders.Customers.CompanyName,
Orders.OrderDate, Orders.RequiredDate
from Orders
а парсер должен привести все это к виду:
-- запрос Бselect Customers.Address,
Customers.City,
Customers.CompanyName,
Orders.OrderDate,
Orders.RequiredDate
from Orders
left join Customers on Customers.ID = Orders.CustomerID
это самый простой вариант запроса, он может быть намного сложнее, т.е со многими вложенными таблицами и пр.
Парсер на C#.
Теперь попробую коротко описать логику работы парсера:
берем первый трэк запроса А:
Orders.Customers.Address,
разбираем его, получаем, что первый элемент трэка, это "Orders" — это FromTable, второй элемент трэка "Customers" — это приджойненная таблица и т.д. по всем трэкам.
Так вот меня интересует не готовое решение, а именно есть ди в C# классы (типа может быть Regex), которые помогут мне решить эту задачу грамотно и не дадут изобретать велосипед.
Всем спасибо.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Den Raskovalov, Вы писали:
DR>>Курим слово ORM. Hibernate, NHibernate для примера. А>В смысле?
В поставленной задаче есть несколько подзадач:
1. Разбор входящего запроса (парсер).
2. Анализ запроса (здесь предложили курить ORM).
3. Генерация измененного запроса (кодогенерация).
1.Парсим:
— если вид запросов предопределен, то можно посмотреть в сторону использования RegExp.
— если произвольный, то либо ищем стандартный SQL парсер от производителя DB (не найдется, наверное), либо, что будет лучше для данной ситуации, пишем свой, например, рекурсивным спуском.
Разбираемся с промежуточным представлением, которое будет порождать парсер:
— модификации запросов простые, фиксирован вид модификаций или схема базы; обходимся без промежуточного представления. Делаем текстовые замены.
— модификации сложные, схема базы не фиксированная — на 1 этапе создаем промежуточное представление.
2. Как доступна информация о схеме базы? Насколько критична скорость?
— если схема базы произвольная, скорость некритична, можно использовать ORM; в качестве промежуточного представления можно использовать те же классы;
— иначе пишем свой модификатор внутреннего представления, как-то снабжая его информацией о схеме базы;
3. Генерация измененного запроса. Тут должно быть все понятно.
Содержательным пунктом видится только 2, поэтому про него и отвечали.
Re[4]: Автоматизация запросов (парсер)
От:
Аноним
Дата:
30.12.05 08:52
Оценка:
В принципе я уже написал классик, который, грубо говоря, парсит указанный выше запрос в нормальный SQL запрос.
Можно было бы конечно выложить, для критики, но боюсь что не всем это интересно, да и завязки с БД должны быть.
А если кому нибудь интересно могу описать способ решения.
Всем спасибо за ответы.
Здравствуйте, andyJB, Вы писали:
JB>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, Den Raskovalov, Вы писали:
DR>>>Курим слово ORM. Hibernate, NHibernate для примера. А>>В смысле? JB>В поставленной задаче есть несколько подзадач: JB> 1. Разбор входящего запроса (парсер). JB> 2. Анализ запроса (здесь предложили курить ORM). JB> 3. Генерация измененного запроса (кодогенерация). JB>1.Парсим: JB> — если вид запросов предопределен, то можно посмотреть в сторону использования RegExp. JB> — если произвольный, то либо ищем стандартный SQL парсер от производителя DB (не найдется, наверное), либо, что будет лучше для данной ситуации, пишем свой, например, рекурсивным спуском. JB> Разбираемся с промежуточным представлением, которое будет порождать парсер: JB> — модификации запросов простые, фиксирован вид модификаций или схема базы; обходимся без промежуточного представления. Делаем текстовые замены. JB> — модификации сложные, схема базы не фиксированная — на 1 этапе создаем промежуточное представление. JB>2. Как доступна информация о схеме базы? Насколько критична скорость? JB> — если схема базы произвольная, скорость некритична, можно использовать ORM; в качестве промежуточного представления можно использовать те же классы; JB> — иначе пишем свой модификатор внутреннего представления, как-то снабжая его информацией о схеме базы; JB>3. Генерация измененного запроса. Тут должно быть все понятно. JB>Содержательным пунктом видится только 2, поэтому про него и отвечали.