Так получилось, что только после того, как я написал первую часть я понял, что создать Excel файл — не фокус, хотя чисто профессионально, это было достаточно трудно. Первая статья состояла из двух частей:
Честно говоря, я думал, что вторая часть важнее, ради нее я и написал статью.
Сейчас я думаю, что тема языка обработки селекта более важна.
Я поискал в интернете и нашел, не сильно затрудняясь, 6 или 7 решений для создания Excel файла из селекта. Я не сомневаюсь, что там были решения получше моего. Но, оказывается, без языка предварительной обработки это ничего не стоит, на мой взгляд. Система, которую я выстроил во многом интуитивно, получается единственно возможной, если мы хотим заменить такую платформу как Oracle*Reports(понятно, мы говорим только о выходных файлах в различных форматах Excel).
Необходимо заготовить текст селекта, отвечающего запросам пользователя.
Это аналогия report(rdf) файла с query, формулами и триггерами. Я писал, можете быть уверены, любой rdf можно свести к одному селекту(или в крайнем случае в «before» PL/SQL блоке реализовать логику и записать в некую таблицу и затем сделать select * from ...).
Прелесть rdf в том, что в нем есть параметры и средства видоизменения query в зависимости от значений, заданных пользователем в runtime.
Это означает, что в хранимом селекте уже прописаны параметры и есть правила(язык) что и как менять в селекте перед выполнением.
Об этом я писал в первой части.
Так как параметры теперь обрабатываются только перед выполнением, необходимо в некоей формализованной форме их определить. То есть задать
Только все вместе это даст хороший эффект, который я наблюдал в нашей компании.Здесь примеры экранов, которые можно написать.
Это написано в Oracle Forms, но точно также можно написать и на любой другой платформе. Два экрана(Администрация и Выполнение) и два PL/SQL пакета в базе, несколько таблиц для хранения данных.
Мы практически отказались от Reports. Аналитики используют Excel, а мы по запросу строим селекты. На это может уходить много времени, и это отладка селекта, и логика и оптимизация. Но затем, в течение 20 минут определяем его в системе и пользователь начинает работать с ним. На мой взгляд, это проще, чем системы типа Business Objects или Oracle Discoverer. Да, это требует работы программиста и DBA, но зато и селекты получаются заточенные и эффективные. А по поводу Excel, как мощного аналитического средства я говорить не буду(не специалист).
- Примерное описание языка предварительной обработки селекта
- Проблемы, которые были решены в процессе написания
Честно говоря, я думал, что вторая часть важнее, ради нее я и написал статью.
Сейчас я думаю, что тема языка обработки селекта более важна.
Я поискал в интернете и нашел, не сильно затрудняясь, 6 или 7 решений для создания Excel файла из селекта. Я не сомневаюсь, что там были решения получше моего. Но, оказывается, без языка предварительной обработки это ничего не стоит, на мой взгляд. Система, которую я выстроил во многом интуитивно, получается единственно возможной, если мы хотим заменить такую платформу как Oracle*Reports(понятно, мы говорим только о выходных файлах в различных форматах Excel).
Нужно хранить текст селектов
Необходимо заготовить текст селекта, отвечающего запросам пользователя.
Это аналогия report(rdf) файла с query, формулами и триггерами. Я писал, можете быть уверены, любой rdf можно свести к одному селекту(или в крайнем случае в «before» PL/SQL блоке реализовать логику и записать в некую таблицу и затем сделать select * from ...).
Работа с параметрами
Прелесть rdf в том, что в нем есть параметры и средства видоизменения query в зависимости от значений, заданных пользователем в runtime.
Это означает, что в хранимом селекте уже прописаны параметры и есть правила(язык) что и как менять в селекте перед выполнением.
Собственно создание Excel
Об этом я писал в первой части.
Единая форма, предлагающая пользователю ввести данные
Так как параметры теперь обрабатываются только перед выполнением, необходимо в некоей формализованной форме их определить. То есть задать
- datatype
- формат ввода
- приглашение для ввода параметра пользователем
- предварительные проверки
- с каким result set проверять параметр
- и так далее
Только все вместе это даст хороший эффект, который я наблюдал в нашей компании.Здесь примеры экранов, которые можно написать.
Это написано в Oracle Forms, но точно также можно написать и на любой другой платформе. Два экрана(Администрация и Выполнение) и два PL/SQL пакета в базе, несколько таблиц для хранения данных.
Мы практически отказались от Reports. Аналитики используют Excel, а мы по запросу строим селекты. На это может уходить много времени, и это отладка селекта, и логика и оптимизация. Но затем, в течение 20 минут определяем его в системе и пользователь начинает работать с ним. На мой взгляд, это проще, чем системы типа Business Objects или Oracle Discoverer. Да, это требует работы программиста и DBA, но зато и селекты получаются заточенные и эффективные. А по поводу Excel, как мощного аналитического средства я говорить не буду(не специалист).