Есть вопрос, на который поисковики пока не дают ответа. Я проектирую систему, и есть необходимость :) проверять формируемые ей sql-запросы. Вручную это делать просто нереально -- тратится много времени.

Существует множество программ для визуального построения sql-запросов, в drag-n-drop-стиле, это все замечательно.

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

Заранее спасибо.

Изопропил

зачем вручную, сервер пущай проверяет :)



Затем, что сервер проверяет только синтаксис.

Изопропил

"разнообразные визуальные построители" - по тексту запроса рисуют красивые картинки, если запрос имеет простую структуру, наприме Microsoft Query.

Сложную :) Можно попробовать и MQ. Похоже, эта задача называется "обратное проектирование", нужно с PowerDesigner поработать...

Глядя на картинку со стрелочками можно убедиться, так ли связываются данные в запросе. Полезно, когда ты не знаешь какой запрос выдаст твоя система, и когда за короткое время нужно проанализировать варианты. (Классическая ситуация -- сравнить с эталоном. Как это сделать?)

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

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

Petro123
Acces - кнопка "в режиме SQL" вставить текст запроса и переключиться в режим "построителя запроса".

Хорошо, но нужно, соответственно, описывать таблицы в Access...

Вполне возможно.
Решил. Надо. IT-специалиста.

Все грустнее и грустнее. Вопрос касается именно sql-запросов, а не разработки новых технологий. Мне жаль вашего и моего времени, если разговора по существу не получится.

-------------------------------------------------
table_bla
-------------------------------------------------
drcl_drcl_id = 30244
del_date is null
end_date >= to_date('01-09-2006','DD-MM-YYYY')
-------------------------------------------------

Предполагаю примерно так.

Petro123
IMHO

вообще то понятие фильтр не имеет никакого отношения к серверу. Только к клиенту.

Физическая реализация фильтра и условия в запросе после WHERE совершенно различная.

ЗЫ. По какому формату/ГОСТУ написан ваш текст выше остаётся догадываться.

Это, вообще-то, визуализация фильтра в той самой картинке, которую нужно получить. Ведь вопрос Как вы предпологаете увидеть в запросе "фильтр" и что это в Вашем понимании? был про это? К чему Вы все это спрашиваете? Выше написано достаточно много, какие исходные данные, и какой нужен результат. Если разбираеть один запрос в день, то можно рассуждать о принадлежности его к какому-либо формату. Здесь за полчаса нужно проанализировать 30-60 текстов sql-запроса и сказать "катит/не катит".

КАКАЯ база, КАКАЯ реализация -- второстепенный вопрос. НУЖНО анализировать только текст. ПОКА не было никаких вариантов.

Я надеюсь, желание понять суть вопроса пересилит стремление свести его к RTFM.

Konst_one, Пробовал, до того, как заводить тему. Не устраивает вот что: нужно заводить коннект. Будет время, попробую еще, спасибо.

RENaissance
IMHO, топик бессмысленен, т.к. не имеет практического решения.


Posted via ActualForum NNTP Server 1.3

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

RENaissance

Готовое решение есть (и давно) - это сам SQL-сервер, который может на основании запроса план выполнения, что и будет являться
результатом разбора. И на плане вполнения Вы увидите и какие таблицы участвовали в запросе, как они объединялись между собой, какие
условия наклдывались и т.д.
З.Ы Расчитывать на то, что появиться программа, которая будет парсить запросы, мягко говоря, не дальновидно, т.к. задача построения
парсера запросов - технически сложная (равносильно написанию собственной СУБД).
З.З.Ы так и не понял, что же курил автор...


Хм... План запроса в Oracle не показывает, как связываются таблицы.
Возможно, ждать было бы глупо. Реализации парсеров sql (текстовых) есть на Java и Delphi, к примеру, достаточно давно. Не буду спорить насчет сложности технической реализации, у меня есть интерес сделать его самому, но пока нет времени и за это действительно не заплатят :)

Считаю, имеет смысл закрыть тему.