CIDC 2015

Shur

OK. Я понял, для того и спросил. Сейчас довольно популярно встраивать скриптовые языки в свои программы. Посмотрите на язык Lua, к примеру. Если бы вам удалось его встроить (а он считается лёгким для встраивания), то пользователи (с IT образованием, конечно же) могли бы сами из базы что-то извлекать.
Альтернативой я бы рассматривал что-нибудь вроде OLAP-продуктов. Там не программировать, но крутить-вертеть кубы тоже можно.
Но это уже другая история.

kreator писал(а): Пользователь может ввести SQL-запрос (как есть, например) и получить результат в виде банальной не форматированной выгрузки в Excel. Но функционал не востребован совсем.

Можно сделать типа библиотеки пользовательских SQL-запросов - то есть самим накидать 5-10 полезных запросов, и давать выбрать из списка, пользователю остаётся только поменять параметры (скажем, период выборки).

Игорь Столяров

Дед Пахом писал(а): пользователю остаётся только поменять параметры (скажем, период выборки).

Или заменить GET на UPDATE и завалить к черту всю БД.

Игорь Столяров писал(а): GET на UPDATE

Для отчетов отдельный юзер с правами на выборку и все!

Игорь Столяров

Admin писал(а): Для отчетов отдельный юзер с правами на выборку и все!

Не всегда так все просто. Например кроме получения отчетов, хотелось бы иметь возможности групповой
обработки справочников или документов (т.е. операции с модификацией списков) и т.д.

Права можно раздавать на каждую таблицу. И как бы даже не на поля. Точно не помню.

kreator

Тема не так проста. "Стандартные" отчёты и выгрузки присутствуют, настраиваемые, с выбором опций, дат и т.д. Но вот кто-то хочет что-либо ещё, абсолютно что угодно. Неизвестно - какие таблицы нужны для этого, какие параметры. Конечно, нужен "скриптовый" язык. И тут же нужен дизайнер отчётов. А ещё нужна, как заметил Игорь Столяров, защита от дурака (напишет запрос "delete all"

). И опять про 1С. Они сразу пошли на это, на разработку встроенного языка, такая бизнес-схема. Правда не могу сказать, что технически всё удачно получилось, скорее наоборот.

Ресурсов не хватит написать такой конструктор с защитой от дурака.

kreator

Нашёл пример. Прислали запрос к БД Firebird (не наша, чужая, СКУД завода) из 1С:

Код: Выделить всё

"ВЫБРАТЬ
                |             ВложенныйЗапрос.EV_DATE, //дата события
                |             ВложенныйЗапрос.RD_NUMBER, //0-вход, 1- выход
                |             ВложенныйЗапрос.OW_IDENT2 // таб.номер сотрудника
                |ИЗ
                |             (ВЫБРАТЬ
                |                             События.EV_DATE КАК EV_DATE,
                |                             READERS.RD_NUMBER КАК RD_NUMBER,
                |                             OWNER.OW_IDENT2 КАК OW_IDENT2
                |             ИЗ
                |                             (ВЫБРАТЬ
                |                                             EVENTS.EV_DATE КАК EV_DATE,
                |                                             EVENTS.EV_CODE КАК EV_CODE,
                |                                             EVENTS.EV_OBJID КАК EV_OBJID,
                |                                             EVENTS.EV_CARDID КАК EV_CARDID,
                |                                             EVENTS.EV_OW_ID КАК EV_OW_ID
                |                             ИЗ
                |                                             ВнешнийИсточникДанных.СКУД.Таблица.EVENTS КАК EVENTS
                |                             ГДЕ
                |                                             EVENTS.EV_DATE МЕЖДУ &ДатаНач И &ДатаКон) КАК События
                |                                             ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВнешнийИсточникДанных.СКУД.Таблица.EVDESC КАК EVDESC
                |                                             ПО События.EV_CODE = EVDESC.ED_CODE
                |                                             ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВнешнийИсточникДанных.СКУД.Таблица.READERS КАК READERS
                |                                             ПО События.EV_OBJID = READERS.RD_ID
                |                                             ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВнешнийИсточникДанных.СКУД.Таблица.OWNER КАК OWNER
                |                                             ПО События.EV_OW_ID = OWNER.OW_ID) КАК ВложенныйЗапрос
                |ГДЕ
                |             НЕ ВложенныйЗапрос.OW_IDENT2 ЕСТЬ NULL ";

Смешно? Мой вариант (собственно почти одно и тоже, во всяком случае по необходимому результату):

Код: Выделить всё

  SKUD{prop:SQL} = 'select e.ev_date, r.rd_number, r.rd_name '                                                                                              & |
                   'from events e inner join evdesc e2 on e2.ed_code=e.ev_code '                                                                            & |  
                   '              inner join readers r on r.rd_id=e.ev_objid '                                                                              & |
                   '              inner join owner o on o.ow_id=e.ev_ow_id '                                                                                & |
                   'where e.ev_date between ''' & format(LOC:Date,@d10-) & ''' and ''' & format(LOC:Date+1,@d10-) & ''' and o.ow_ident2=' & SOT:TAB & ' '   & |
                   'order by e.ev_date'

Вот и сто раз подумаешь, а нужны такие извращения?

RaFaeL

kreator писал(а): "Стандартные" отчёты и выгрузки присутствуют, настраиваемые, с выбором опций, дат и т.д. Но вот кто-то хочет что-либо ещё, абсолютно что угодно. Неизвестно - какие таблицы нужны для этого, какие параметры.

В нашей CRM есть большой модуль "выборки", там параметров на пару экранов (в каждом внутри еще списки, условия и т.п.), настройка списка - еще пара экранов. Так пользователи даже с таким интерфейсом не могут сделать выборку по своим условиям. Не понимают, чем глобальное "И/ИЛИ" отличается от "И/ИЛИ" внутри параметра (а если там еще "НЕ"...), путают объекты (человека, кому звонили с записью о совершенном звонке) и т.п. Какие там SQL запросы, не будет этим никто пользоваться. Пишите себе редактор запросов и продавайте готовые отчеты (только не прибитые к программе гвоздями, а дополнительные). Правда хранить SQL запрос в таком отчете тоже не советую

kreator писал(а): Вот и сто раз подумаешь, а нужны такие извращения?

Для таких извращений есть view.

kreator

RaFaeL писал(а):Какие там SQL запросы, не будет этим никто пользоваться.

Да согласен на 100%, не востребовано. Да и ресурсов нет, как заметил Admin. Не та бизнес-схема. Легче, действительно, продавать отчёты.

Дед Пахом писал(а):Для таких извращений есть view.

Возможно, это бы упростило бы. Но view должен сделать разработчик, а он откуда знает, что надо? И есть интересный момент касаемо Вьюх в Firebird'е. Работают исключительно медленно. Не можем с ними справится, по возможности не используем.

Shur

Снова возвращаясь к скриптовому языку.
Схема действий там примерно такая (как я видел в одной из реализаций): имеется ядро языка в виде dll, к нему пишется ваша dll, в которой могли бы быть разные функции, например: getClientInfo(), getTradeInfo() и т.д. Так что абы чего там сделать не удастся, но и сломать не получится тоже, если вы не дадите возможности записи в БД.
Далее из меню вашей программы делается запуск функции ядра, выполняющей пользовательский скрипт, который дёргает функции из вашей dll для доступа к данным.
Сам язык высокоуровневый. Со всеми полагающимися операторами циклов, ветвления. Извлечённые данные хранит в массивах. Умеет читать из файла и записывать в файл.
В реализации, что я видел, умеет выгонять данные в окно основного приложения в виде грида.

Игорь Столяров

Shur писал(а): который дёргает функции из вашей dll для доступа к данным.

Что-то в этом направлении мы делали для генерации прайс-листов в HTML.
Курсор бежит по списку прайса, но выходная строка рассчитывается через Evaluate(MyFormula).
Так вот в формуле кроме полей были забиндены функции, которые возвращали значения, в т.ч. и по заданным параметрам из БД.
В результате пользователь мог сам собрать нужную ему выходную строку. Убого, но работает ...

kreator

Я что-то смысла использовать сторонний язык, пусть и продвинутый, не вижу. Вообще в Кларионе есть оператор Evaluate, который выполнит любой скрипт в рантайме. С SQL тоже не проблема, через prop:SQL в рантайме можно получить всё. Вопрос в том, чтобы дать пользователю простой механизм генерации запросов к БД, или/и генерации разных функций.
Я через Evaluate делал, например, настройку бухгалтерских проводок документа. У документа (например, накладной) есть какие-то значения - Сумма, Сумма НДС, Сумма без НДС и т.д. Пользователь хочет, чтобы в базу писалось значение:

Код: Выделить всё

{Сумма}*5 - {СуммаБезНДС} - {СуммаНДС}*2

Всё работает. Пример дурацкий, под рукой конкретики нет, не суть.
Когда совсем всё просто (как в этом примере), то работает на УРА. При усложнении желаний и подходов не работает.