Существуют ли визуальные средства для составления (простых) SQL запросов ориентированных на простых пользователей нашел пока только это ( http://www.activequerybuilder.com/ ), но компоненты ориентированны все же на опытного пользователя. Существует ли что-нибудь с более простым интерфейсом?

гм...
ИМХО, не бывает "простого пользователя", который может составлять SQL-запрос.

А так - Select * from table.  :)

> [1] Ega23 ©   (05.12.08 16:54)

Я тоже пока склоняюс к этому, но вдруг? :о)

> Я тоже пока склоняюс к этому, но вдруг? :о)


Вдруг, пардон, бывает только пук.
Просто нецелесообразно это. Продвинутый человек будет сам нормально запросы писать. Если это в рамках какой-то системы для тупых пользователей делать, то им не нужно Select * from Persons where PersName like('%ов') and ....
Им нужна формочка, где будет чекбокс и "имя как " ...

> ANTPro  (05.12.2008 16:49:00)  [0]

Их просто гигантское количество штук.
А простой запрос, частный случай сложного.

> ANTPro ©   (05.12.08 16:49)  


Виз.конструктор запросов от MS Access - куда уж проще

> [4] Anatoly Podgoretsky ©   (05.12.08 17:04)

И где можно посмотреть хотябы на один экземпляр из этого гиганского множества? Что-то пока не гуглиться простой интерфейс :(

> [5] Сергей М. ©   (05.12.08 17:06)

Возможно, но даже он является не простым. (да и в виде компонента для .NET его не достать :(  )

> И где можно посмотреть хотябы на один экземпляр из этого
> гиганского множества? Что-то пока не гуглиться простой интерфейс
> :(

Запросная система - штука сложная и дорогая. И, как правило, либо заточена под конкретную базу, либо примитивна и непонятна пользователям.

> [8] ANB   (05.12.08 17:14)

Нужна «Запросная система без привязки к конкретной БД примитивная понятная пользователям, пусть дорогая» о как :о)

ANTPro ©   (05.12.08 16:49)
Для какой задачи?
Я ограничился тем что подключаю пользователям представление в Exсel, а они там уже занимаются - фильтруют, крутят как им надо.
Но этих пользователей я бы не назвал простыми.

> без привязки к конкретной БД


А откуда будут браться имена и типы объектов (таблицы, запросы, ХП, вью, функции и т.д. и т.п.), участвующих в проектируемом запросе ?

> [11] Сергей М. ©   (05.12.08 17:22)

Имена будут браться из метаданных(никаких вью и хп, функций) только простые запросы.(Пока еще не понятно как будет проект «выглядеть в целом» вот и ищу отдельные компоненты о которых знаю мало)

> [10] stas ©   (05.12.08 17:21)
> Для какой задачи?
> Я ограничился тем что подключаю пользователям представление
> в Exсel, а они там уже занимаются — фильтруют, крутят как
> им надо.

Такой вариант не походит.

> Нужна «Запросная система без привязки к конкретной БД примитивная
> понятная пользователям, пусть дорогая» о как :о)


гм... Да фиг ты её такую найдёшь. И, откровенно говоря, коль она ещё и к конкретной СУБД не привязана - фигня будет полная.

Сама по себе задачка достаточно интересная, я бы с удовольствием взялся, если бы кто-то финансирование объявил. Но не объявят, ибо - бесперспективно.

К сожалению.

> ANTPro ©   (05.12.08 17:19) [9]
>
> > [8] ANB   (05.12.08 17:14)
>
> Нужна «Запросная система без привязки к конкретной БД примитивная
> понятная пользователям, пусть дорогая» о как :о)


Глупость несусветная.

Делал, как-то, OLAP систему на основе реляционной СУБД ( причем тип СУБД к которой можно обращаться из одного и того же клиентского приложения, практически произвольный - Firebird, Oracle, MSSQL и пр)
Юзеры ставят всякие галочки на понятных им сущностях, вибирают нужное им сечение многомерного куба - вуаля, запрос автоматически готовится и выполняется )
Но чтобы к произвольной по архитектуре БД - бред, по мойму.

> Нужна «Запросная система без привязки к конкретной БД примитивная
> понятная пользователям, пусть дорогая» о как :о)

Запросная система к БД МВД (не очень сложная, но зато объемная БД на оракле) обошлась МВД в несколько миллионов баксов.

Координаты разработчиков дать ?

> [13] Ega23 ©   (05.12.08 17:41)

На реализацию очень мало времени, поэтому ищу готовое.
Пока многое еще неизвестно, может и финансирование будет :о) Так как работы в целом по проекту опять вагон :(

> Пока многое еще неизвестно, может и финансирование будет
> :о)

ICL, Казань. Я себе даже комиссию трясти не буду, можешь напрямую обратиться :)

> [17] ANB   (05.12.08 18:17)

Я не считаю что все настолько сложно (во многих местах можно упростить к примеру все поля только текстовые никаких вычислений в SQL и прочего (так для примера, точных упрощений пока незнаю) )

> Существует ли что-нибудь с более простым интерфейсом?




[     [v]] - это комбик, [         ] - поле ввода (их два, если between и одно при всех остальных)
кроме Equal может быть Like, Between, Less, More
при нажатии Add condition выбирается AND или OR с предыдущим
Если нужны еще хитрые скобки, будет чуть посложнее.
Пробегаем в цикле по всем контролам и составляем select.
Набор контролов для задания условия удобно сделать отдельным компонентом

> clickmaker ©   (05.12.08 18:36) [19]

Ну по одной табличке еще как то можно но IN уже не учтен.
Но даже по одной не все так просто, например
where
(N1 = 5 or N2 = 6) and (N4 = 8 or (N5 = 6 and N7 = 8))

Неискушенный юзер в таком запросе запутается. Даже мне понятнее со скобками.

> [20] ANB   (05.12.08 18:40)

ну понятно, что там должны быть все возможные операторы, в т.ч. Less or equal, more or equal
если нужны скобки, то по нажатию Add condition можно кроме and/or предлагать либо открыть скобку, либо закрыть последнюю открытую. Тогда набор условий внутри скобок более наглядно отображать с отступами.
Для нескольких таблиц, выбираем что-то типа
Join: [inner/outer/full] [Table name] on [MainFieldName] = [JoinedFieldName]

Но в простейшем варианте пишется это примерно за день, может даже за несколько часов.
Потом уже можно наворачивать

Вообще-то первоначально SQL так и задумывался.

Для людей.

Предполагалось, что любой работник, я уже не говорю о топ-менеджере с высшим образованием, сумеет заюзать SELECT, если он не идиот, конечно.
Возьмет перечислит таблицы, укажет условия в WHERE, а сервер соптимизирует запрос, а программист продумает индексы.

Но люди оказались намного тупее, чем полагали создатели SQL.
И оказались не в состоянии осилить даже самые простые внутренние объединения с агрегатами и группировками, которые в большинстве случаев с лихвой удовлетворили бы их потребности в таких вещах как "хочу знать суммарные доходы с разбивкой по годам".

Может нет смысла заново проходить тот же путь?
Хотя чем черт не шутит...
Иногда юзеры проявляют удивительную изобретательность в Excel-е, например. Может действительно можно сделать что-то дружественное для юзера?

> ANTPro ©   (05.12.08 18:22) [18]
> Я не считаю что все настолько сложно

Ну так сделай, если не настолько сложно.
Если не можешь, то, право, не стОит молоть языком зазря... Если  же в сказки ещё веришь, то пожалуйста, верь и дальше. У нас свобода совести...
Но мы к твоей вере никакого отношения не имеем. Как и весь мир.

> kaif ©   (05.12.08 19:01) [22]


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

и, я предполагаю, в те времена простые юзеры простые запросы писали. Ты не забывай, что тогда в командной строке работали и скрипты простенькие писали.

Мне кажется, что юзер любит сразу видеть результат.
Если сделать так, что по мере конструирования запроса, система будет выдавать какие-то частичные результаты: сама ограничивая наборы по объему, вводя дополнительные условия за кадром и следя за тем чтобы юзер не устроил декартово произведение сдуру на большом наборе, предвосхищала бы примерно время, которое он получит в "рабочем" варианте, то что-то подобное могло бы оказаться полезным. И не только юзерам, но и нашему брату SQL-щику.

Вообще-то первоначально SQL так и задумывался. Для людей
Люди разные бывают.
Может действительно можно сделать что-то дружественное для юзера?
У ANTPro ©   (05.12.08 18:14) [16] Пока многое еще неизвестно, может и финансирование будет
А вы ему значит помочь хотите с финансированием? :)
Или на халяву ?

Petr V. Abramov ©   (05.12.08 19:06) [24]
и, я предполагаю, в те времена простые юзеры простые запросы писали.

Готов согласиться. А куда им еще было деться?

2 blackman ©   (05.12.08 19:07) [26

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

> ANTPro  (05.12.2008 18:14:16)  [16]

О да ты еще и спонсируешь предприятие.

все уже украдено до нас. точнее до вас.
и без дурацких (а все они дурацкие) построителей запросов.

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

> kaif  (05.12.2008 19:01:22)  [22]

ИБМ много чего не учла, например Билл Гейтса.
А продуктов запороло очень много.

> Petr V. Abramov  (05.12.2008 19:06:24)  [24]

И ввод был из телетайпа, оттуда и символ точка с запятой, и вывод был на телетайп.

> blackman  (05.12.2008 19:07:26)  [26]

Какое на халяву, только пилить Шура.

kaif ©   (05.12.08 19:10) [28]
Идея как я понял, заключается в том, что бы на халяву получить построитель запросов для тех кто этого делать не умеет.
Можно конечно и в Excel кидать или то, что Поросенок Винни-Пух предлагает. Наконец наплодить какую-то стандартную серию или даже построитель как в Access. Но все зависит от того кто будет пользователем.
Подавляющее большинство НЕ будет ничего строить, а будет звать программиста и с его помощью...
Я обычно прошу нарисовать все возможные отчеты которые юзер хотел бы получать. Это обязательное требование на начальном этапе.
Обобщаю написанное, меняю так что бы это действительно были отчеты.
Показываю и согласовываю. После того как все готово доделываем те, что были и дополняем новыми.
Обычно этого хватает. Если нет, то делаем вторую очередь, за дополнительные бабки и доп. время.
Расчитывать на умного юзера я уже давно перестал. Не бывает. А если и появляются, то лучше не заморачиваться с их сверхидеями.

Я обычно прошу нарисовать все возможные отчеты которые юзер хотел бы получать. Это обязательное требование на начальном этапе.

Во! Правильно!
Сразу задать юзеру вопрос на который точно нет ответа
:)))

kaif ©   (05.12.08 19:10) [28]
Забыл добавить, что браться за бесплатные идеи можно только если ты хорошо обеспечен :)

Anatoly Podgoretsky ©   (05.12.08 19:42) [33]
Какая же там халява. Золото обещали. Обманули конечно. Но хотя бы обещали...

> blackman  (05.12.2008 20:01:36)  [36]

В данном случае не обманут, не гирю же пилить, а эквивалент золота.

Поросенок Винни-Пух ©   (05.12.08 19:59) [35]
Сразу задать юзеру вопрос на который точно нет ответа
Ты не прав. Если юзер не знает, чего он хочет от системы, то и начинать не стоит.
Другой вопрос, что он часто как собака, все понимает, но сказать не может.
Но тут уж ты сам должен ему помочь. Объяснить, что можно и в каком виде. Примерчики привести. Уверяю тебя, что он нарисует. Пусть и бред в первой редакции, но опять скорректировать можно и добиться взимной радости от общей работы.
Надо также учесть, что в большинстве случаев все отчеты он уже делал раньше ручками. Можно покопаться в его бумажках. Посмотреть, что он делал и куда, кому...
Абсолютно новых задач давно уже нет.

Anatoly Podgoretsky ©   (05.12.08 20:04) [37]
Где же этот эквивалент? Может я самое важное пропустил? ;)

Anatoly Podgoretsky ©   (05.12.08 20:42) [40]
Как оказалось не хотят. Только обсудить и тоже на халяву :)

> blackman  (05.12.2008 20:46:41)  [41]

Надо не говорить, а пилить.

Anatoly Podgoretsky ©   (05.12.08 22:21) [42]
Когда есть что и это что золото
А пока остается только говорить... :)

Microsoft Query
Это ексель->Data->Import External data

Тест для простого пользователя - конструирование сводной таблице в ёкселе. 90% не могут. Остальные 10% можно допускать к конструктору акцесса.

> ANTPro ©

Pentaho - программное обеспечение бизнес-интеллекта (BI) с открытым кодом.
http://ru.wikipedia.org/wiki/Pentaho

> [19] clickmaker ©   (05.12.08 18:36)

Это интересный вариант, хотя если присмотреться, то везде похоже сделано.
Возможно в виде мастера такая реализация будет проще для пользователя.

> [46] Омлет   (06.12.08 23:24)

Спасибо посмотрю.

> [44] Карелин Артем ©   (06.12.08 11:18)

Тут слишком много кнопочек :о)

Я как-то на старой рботе видал такую штуку - Bussiness Objects называлась. В деталях не помню, но вроде как, к большинсту СУБД подрубалась и могла всякие отчеты на основании имеющихся данных строить. Правда, дорогучая, вроде, была. Да и обучения некоторого требовала, но менеджеры вроде как справлялись.

> Ega23 ©   (05.12.08 16:54) [1]
>
> гм...
> ИМХО, не бывает "простого пользователя", который может составлять
> SQL-запрос.
>
> А так - Select * from table.  :)


Бывает. Hibernate в Java, там можно тупо прописать мапинги таблиц и связей в xml и движок сам построит запросы, причём оптимизирует запрос под выбранный сервер. Не визуально, но проще чем писать самому.

А вообще ищи про ORM http://ru.wikipedia.org/wiki/ORM

Где все данные можно представить в виде объектов, но для Delphi ничего толкового нет(сам писал минидвижок), только для Delphi.Net

> kaif ©   (05.12.08 19:06) [25]
> Мне кажется, что юзер любит сразу видеть результат.
> Если сделать так, что по мере конструирования запроса, система
> будет выдавать какие-то частичные результаты: сама ограничивая
> наборы по объему, вводя дополнительные условия за кадром
> и следя за тем чтобы юзер не устроил декартово произведение
> сдуру на большом наборе, предвосхищала бы примерно время,
>  которое он получит в "рабочем" варианте, то что-то подобное
> могло бы оказаться полезным. И не только юзерам, но и нашему
> брату SQL-щику.

1. Очень сложно получится перехватывать все дури юзера (предотвращение кортезианов (хотя иногда кортезиан - как раз то, что нужно), вытаскивание всей таблицы (на пару миллиардов записей)). В общем случае, запросы, писанные как попало, будут работать на достаточно небольшой базе и при условии мощного сервера. Хотя кортезианами можно и малым обьемом сервер уложить.
2. Все равно получится сложно и юзеры будут звать программиста. Примеров куча : тот же SQL, 1С . . . (изначально задумывалось, что программист будет не нужен).

Так что :

> blackman ©   (05.12.08 19:54) [34]

+1.

> kaif ©   (05.12.08 19:06) [25]
> Мне кажется, что юзер любит сразу видеть результат.
> Если сделать так, что по мере конструирования запроса, система
> будет выдавать какие-то частичные результаты: сама ограничивая
> наборы по объему, вводя дополнительные условия за кадром
> и следя за тем чтобы юзер не устроил декартово произведение
> сдуру на большом наборе, предвосхищала бы примерно время,
>  которое он получит в "рабочем" варианте, то что-то подобное
> могло бы оказаться полезным. И не только юзерам, но и нашему
> брату SQL-щику.

1. Очень сложно получится перехватывать все дури юзера (предотвращение кортезианов (хотя иногда кортезиан - как раз то, что нужно), вытаскивание всей таблицы (на пару миллиардов записей)). В общем случае, запросы, писанные как попало, будут работать на достаточно небольшой базе и при условии мощного сервера. Хотя кортезианами можно и малым обьемом сервер уложить.
2. Все равно получится сложно и юзеры будут звать программиста. Примеров куча : тот же SQL, 1С . . . (изначально задумывалось, что программист будет не нужен).

Так что :

> blackman ©   (05.12.08 19:54) [34]

+1.

> Я как-то на старой рботе видал такую штуку - Bussiness Objects
> называлась. В деталях не помню, но вроде как, к большинсту
> СУБД подрубалась и могла всякие отчеты на основании имеющихся
> данных строить. Правда, дорогучая, вроде, была. Да и обучения
> некоторого требовала, но менеджеры вроде как справлялись.
>

У нас стоит. И к ней 2 отдела программистов :)

> asail   (07.12.08 23:10) [48]

+1

> ANB   (08.12.08 10:43) [51]


Ну так пропишите мапинги таблиц и будет вам счастье. Запросы будет стоить система, а кривой мапинг визуально обнаружить проще чем муторный запрос.

> ANB  (08.12.2008 10:43:51)  [51]

> тот же SQL, 1С . . . (изначально задумывалось, что программист будет не нужен).

И здесь тоже, видимо тоже лавры IBM не дают.

> Ну так пропишите мапинги таблиц и будет вам счастье. Запросы
> будет стоить система, а кривой мапинг визуально обнаружить
> проще чем муторный запрос.

И запросы будут строить наши юзеры ?

Я лучше сразу пойду застрелюсь вместе с DBA.

> ANB  (08.12.2008 13:00:57)  [57]

Для проверки, первым пусти DBA

> ANB   (08.12.08 13:00) [57]


А щапрос будет в такой вот форме




http://habrahabr.ru/blogs/java/29694/

Я пентаху (ссылка выше) видел в деле - интересная штука. И бесплатная. Но местами требует напильника. Кстати там, как раз таки сразу видно результат среза данных, все гибко и очень мощно.
Хибернат? Не смешите меня, менеджеры (тем более топы) не смогуть его освоить, и не захотят. Он не так прост на практике.

> Омлет   (08.12.08 21:34) [60]


так хибернетй не для менеджеров, а для программистов. А менеджер вообще в систему лезть не должен.

Интересно, почему автор не желает освоить акцесовский мастер запросов чтобы убедиться как он неудобен для человека хотя бы элементарно знакомого с SQL. Чтобы навсегда оставить эту бредовую идею.
К тому же "черный" прав - юзеры все равно будут звать программист чтобы он набрал простейший запрос типа Select * from Personal where Oklad between 10000 and 20000

> Городской шаман

Так тема обозначена как SQL людям, а не программистам.
Или ты предлагаешь самостоятельно написать универсальную систему бизнес-анализа, используя гибернат?

> Омлет   (08.12.08 21:45) [63]
>
> > Городской шаман
>
> Так тема обозначена как SQL людям, а не программистам.
> Или ты предлагаешь самостоятельно написать универсальную
> систему бизнес-анализа, используя гибернат?


Ну программисты бывают ленивые, вот мне лично облом уже думать как оно там должно оптимизироваться, мне больше понравилась модель ORM, где за тебя может подумать программа и создать запрос, а ты всего лишь описываешь мапинги объектов.

Хороший программисты - программист, пишущий одну строчку кода в день...

> [62] MsGuns ©   (08.12.08 21:45)

Освоил, понял что это не удобно. Вот и спрашиваю есть ли чтонибудь лучше чем «это».

> [50] Городской Шаман   (08.12.08 00:12)

Интересно, спасибо. Кстати как раз под .Net и нужно.

> Ну программисты бывают ленивые, вот мне лично облом уже
> думать как оно там должно оптимизироваться, мне больше понравилась
> модель ORM, где за тебя может подумать программа и создать
> запрос, а ты всего лишь описываешь мапинги объектов.

Это проканает :
1. На DWH
2. На маленькой базе

На нормализированной большой OLTP базе без ручной оптимизации, к сожалению, не обойтись.

> ANB   (10.12.08 15:00) [66]


3. Если при проектировании базы учитывалась ORM, а не ручное составление запросов.

> 3. Если при проектировании базы учитывалась ORM, а не ручное
> составление запросов.

Если база писалась в 90-м году под битрив, а потом сконверчена в оракл, то хрен что учтешь.