Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Может не совсем про с++, но реализовывать надо на них. Условия: Есть база данных, есть много-много таблиц с различными типами данных. Есть клиент, который эти таблицы показывает. У таблиц есть колонки С1...СN, на них можно накладывать условия, в зависимости от их типов. Эти условия можно комбинировать по и/или, скобками, т.е. собирать логические выражения, где могут участвовать любые колонки в любом порядке. Потом это всё собирается в sql-запрос и отдаётся в базу данных. Задача: Сделать окно создания/редактирования фильтра (для последующего наложения фильтра на таблицы). Редактор фильтров. Простой. Удобный. Наглядный. Данные только из одной таблицы, т.е. привязки к другим таблицам не нужны. Сложные навороты не нужны. Нужно чтобы простому юзеру можно было быстро накидать условия, и чтобы при взгляде на окно редактора, было понятно, что там написано. Мне хотя бы просто концепт такого редактора, как что выглядит, где что расположено, и как редактировать и просматривать. Сейчас это сделано в виде таблицы, и я не могу ничего придумать, фантазии у меня нет. Подозреваю, подобные редакторы уже есть. Может быть, даже с исходным кодом. Капча изумительна!!! ^_^ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 09:50 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
siebentearbeitПодозреваю, подобные редакторы уже есть MS Acccess, например ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 09:53 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Посмотри как в MS Access или MS Managment Studio построитель запросов сделан. Почтовый клиент The Bat - настройка сортировщика писем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 09:57 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Bat довольно прост (в MS Outlook так же примерно). А вот MS Access подразумевает наличие ручного редактирования. А это подразумевает, надо будет проверять правильность введённого выражения, это не хочется делать, сейчас этого нет, всё набирается "кубиками". Вот если бы "кубики" легко можно было комбинировать со скобками и логическими операторами, было бы классно. Но как это просто сделать, я вообще не могу придумать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 10:20 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Очень важно для кого это всё делается. Есть варианты 1) Обучалка для детей. Нужно всё делать наглядно. Красиво. С анимацей. C хинтами и голосовым сопровождением. 2) Тулза для бизнес-пользователя. Тут надо подумать. Пользователь может "фабриковать" семантически верные простыни кода но запрос может иметь плохой план или высокую сложность из-за ненужных order by, group by e.t.c. Во времена Oracle 9i я пытался писать нечто обратное. Java-standanlone приложение, которое собирало сведения рабочей нагрузке из v$sql/v$session в разрезе пользователей и таблиц. Я его так и не окончил. Бросил на том что не смог написать полный синтаксис SQL для antlr/javacc. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 10:27 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
CEMbВот если бы "кубики" легко можно было комбинировать со скобками и логическими операторами, было бы классно. Но как это просто сделать, я вообще не могу придумать В Bat`е это есть, там две кнопки: "добавить" и "добавить блок", второе аналог подвыражения в скобках. Не сказать что идеально сделано, но достаточно гибко. Визуально тоже относительно неплохо. ИМХУ Рядовой юзер, незнакомый с логическими выражениями, не сможет сложное условие написать, а тому кто знаком - удобнее видеть в обычном виде: в строку со скобками и т.д. Как вариант может просто два режима предусмотреть: простой с минимумом функционала и продвинутый (пиши в строку хоть трехэтажные выражения). PS В построителе еще надо учитывать приоритеты операций, юзер может быть не в курсе что сначала выполняются все И, а затем ИЛИ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 10:36 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
siebentearbeit, я дерево использовал. Идею подсмотрел в фильтре от Dev Express: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 10:57 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Попытка описать задачу приводит к более ясному пониманию :) Всё делается для бизнес-юзера. На 90% я уверен, что юзеры используют в 90% случаев одну колонку и одно условие . Т.е. текущая реализация подходит очень идеально под эти случаи: юзер увидел нужную строку в таблице в окне фильтра, нажал на ячейку, выпало окно выбора условия, он задал условие, ОК, ОК - всё, данные получены. Но вот дальше, дальше начинается сложно. Сейчас нельзя ни расставить скобки, ни выбрать какими операциями конкатенуются выражения, это всё железно прошито. Т.е. для одной колонки ты можешь тем самым образом задать одно условие, потом ещё одно, потом ещё, ещё, все они по одной прошитой формуле будут накладываться на колонку. Потом все условия на колонки соберутся в одно условие через (железно прошитое) И, и всё. Вот хочется упростить эти 10% случаев, не поломав существующую простоту в тех 90% :) И ещё один момент. Сейчас это таблица(в одной ячейке - одно выражеие). Хочется, чтобы это осталось таблицей - всё упирается в деньги, чем больше переделок, тем скорее всего это завернут по причине "неее, дорого, мля!" ((с) анекдот). А мы - добрые девелоперы, хотим сделать хорошо юзерам. Ещё одна причина таблицы - привычность юзеров. Они сильно пугаются всего нового ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 11:40 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
В процессе эксплуатации "графического редактора логических выражений" выяснилось, что 99,99% от всех пользователей оказались не способны построить сколь-либо сложное выражение. А простые выражения в работе им практически и не нужны. Другое дело, что такой графический редактор хорош для демонстрации возможностей вашей системы. Продавцы-демонстраторы показывают, как все просто, гладко и сладко. А глупые клиенты с радостью покупают. Полезно, но на этапе продажи. По сему, есть смысл оставить возможность создавать (и хранить) обычные SQL - запросы (параметризованные). Чисто для создания сложных запросов. Тем более, что sql - запросы могут включать в себя более сложные вещи, чем простые логические выражения. Например, можно использовать анонимные блоки, подзапросы и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 12:45 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Я не верю в пользователя который каждый день конструирует свои запросы. Ему нужен десяток шаблонов (а еще лучше форм (Самое время позвать аналитика ага)) куда надо вписать искомые параметры. И я также знаю что пользователю недосуг заниматься ерундой. Ему надо делать свою работу. А работа - это суть 10 параметризированных шаблонов. Остатки на складе, магазин, клиенты, заказы.... e.t.c. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 12:55 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
maytonЯ не верю в пользователя который каждый день конструирует свои запросы. ... А работа - это суть 10 параметризированных шаблонов. Остатки на складе, магазин, клиенты, заказы.... e.t.c. Не всегда. Иногда нужен просто поиск по БД. И может потребоваться найти все, что угодно. И в "10 параметризированных шаблонов" можно не уместится. Ну или, как пример, аналитика (DWH). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 13:04 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Аналитик работающий с DWH это непростой пользователь. И чаще всего он не новичок и пришёл на работу уже со знанием OLAP/DWH sowtware. Я для простых как угол дома пользователей которые хотят сделать "Like a Google" поиск - можно дейстивтельно отказаться от построителя выражений вообще и дать им только одно поле Text: где можно вбивать любую инфу и искать ее по конкатенации всех полей... (собсно технический аспект можно обсудить позже - главное здесь упрощение интерфейса). А что? Это модно. Это трендово. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 13:11 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
mayton... Я для простых как угол дома пользователей которые хотят сделать "Like a Google" поиск - можно дейстивтельно отказаться от построителя выражений вообще и дать им только одно поле Text: где можно вбивать любую инфу и искать ее по конкатенации всех полей... (собсно технический аспект можно обсудить позже - главное здесь упрощение интерфейса). А что? Это модно. Это трендово. + плюсуюсь В конце 90-х примерно так и делал. Мало того, еще и внешний вид делал "a la HTML". Т.к. то, что внутри данные размазаны по полям и справочникам, пользователя интересует мало. Ему в 90% достаточно смотреть на данные в виде "как в результате/отчете". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 13:14 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
чччД, Параметризированные sql-запросы хранятся, точнее, типы фильтров, и их параметры, на основе которых формируются запросы. Это всё хорошо завизуализировано и удобно по доступу(хотя мне не нравится, может я про это отдельно спрошу). Вот как раз вопрос, как из этого всего формировать сложные запросы/фильтры, когда у тебя под руками только таблица. mayton Например, операционисты банка. Селект по клиенту, по счёту, по периоду даты, по ещё каким-то неведомым хреням, которые выдумали бизнес-аналитики и бизнес-программеры -- таких фильтров за день по разным полям и по разным условиям наберётся до тысячи у одного юнита. Ну ладно, до сотни, всё равно много. Аналитики посмотрели на меня усталым добрым взглядом, и я понял, что я теперь аналитег. У пользователя работа - искать быстро данные, а потом что-то с ними делать. Таблиц может быть очень много. Задать на всё шаблоны нереально. Да и это усложнит жизнь юзера, ему ещё надо будет в шаблонах рыться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 13:16 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
mayton... Я для простых как угол дома пользователей которые хотят сделать "Like a Google" поиск - можно дейстивтельно отказаться от построителя выражений вообще и дать им только одно поле Text: где можно вбивать любую инфу и искать ее по конкатенации всех полей... (собсно технический аспект можно обсудить позже - главное здесь упрощение интерфейса). А что? Это модно. Это трендово. Так и есть. В дополнение к "фильтру для умных" ( 18927088 ) мы в итоге добавили "Stupid filter": три поля, в первом выбирается столбец отображаемой таблички, во втором - условие, в третьем - значение. Жмешь ОК - получаешь результат. К условию можно добавить следующее условие, все условия будут склеиваться по AND. Этим все и пользуются, когда нужно найти что-то, выходящее за рамки готовых шаблонов. Еще лучше, имхо, был бы поиск просто "по тексту". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2016, 13:19 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
CEMbПопытка описать задачу приводит к более ясному пониманию :) Всё делается для бизнес-юзера. На 90% я уверен, что юзеры используют в 90% случаев одну колонку и одно условие . Т.е. текущая реализация подходит очень идеально под эти случаи: юзер увидел нужную строку в таблице в окне фильтра, нажал на ячейку, выпало окно выбора условия, он задал условие, ОК, ОК - всё, данные получены. Но вот дальше, дальше начинается сложно. Сейчас нельзя ни расставить скобки, ни выбрать какими операциями конкатенуются выражения, это всё железно прошито. Т.е. для одной колонки ты можешь тем самым образом задать одно условие, потом ещё одно, потом ещё, ещё, все они по одной прошитой формуле будут накладываться на колонку. Потом все условия на колонки соберутся в одно условие через (железно прошитое) И, и всё. Вот хочется упростить эти 10% случаев, не поломав существующую простоту в тех 90% :) все правильно, я бы еще хотел заметить, что на первое время можно вообще плюнуть на ИЛИ (дизьюнкция), поскольку она очень редко используется, и строить все на основе коньюнктивных термов, а дизьюнкция позволять только как один из элементов коньюнктивного терма , т. е. ИЛИ будет только в скобках внутри И. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 09:54 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
maytonЯ не верю в пользователя который каждый день конструирует свои запросы. есть пользователи, которые предпочитают собственно SQL Узок круг этих революционеров. Страшно далеки они от народа(c) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 10:13 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
MasterZivвсе правильно, я бы еще хотел заметить, что на первое время можно вообще плюнуть на ИЛИ (дизьюнкция), поскольку она очень редко используется, и строить все на основе коньюнктивных термов, а дизьюнкция позволять только как один из элементов коньюнктивного терма , т. е. ИЛИ будет только в скобках внутри И. Ну вот оно сейчас так и есть. Я вчера-таки докопался до аналитиков, в процессе выяснилось, что мы нифига не знаем, что живым юзерам на самом деле надо, так как фидбака никакого ни у кого на руках нет :( Поэтому решили сам редактор не трогать вообще, а только прикрутить несколько удобств для работы с существующим функционалом. Такие дела :[ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 10:17 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
чччДsiebentearbeit, я дерево использовал. Идею подсмотрел в фильтре от Dev Express: ниче так... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 10:52 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevmaytonЯ не верю в пользователя который каждый день конструирует свои запросы. ... А работа - это суть 10 параметризированных шаблонов. Остатки на складе, магазин, клиенты, заказы.... e.t.c. Не всегда. Иногда нужен просто поиск по БД. И может потребоваться найти все, что угодно. И в "10 параметризированных шаблонов" можно не уместится. Ну или, как пример, аналитика (DWH). не, все правильно, Марк прав. Если пользователи начинают писать запросы, это труба, во-первых, для БД, потому что уложат, во-вторых, для разработчика, потому что "ну вот же у меня все работает, только немного неправильно, чуть чуть подправьте, и мне больше ничего не надо! " Семь красных перпендикулярных линий, две - прозрачным цветом. так что юзер -- аналитик -- постановка задачи -- ТЗ -- программист -- запросы -- юзер. и на любом этапе юзера можно послать... я как бы за свою карьеру нарывался раз 20 на эти грабли, на эту дилемму, это просто тупо не работает, даже если сделаешь, то юзеры тупят, ничего не делают сами, и в итоге нанимается какой-то полупрограммист (обычно умная девочка), которая пишет в этом генераторе запросы за пользователей и отдает им, а они юзают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 11:12 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
MasterZivЕсли пользователи начинают писать запросы.... Никто не говорит, что он будет писать SQL. Но я знаю целый ряд задач, где поиск нужен крайне не формализованный. Наверное, такое бывает редко, но формализовать не возможно. Т.е. или решения вида " a la google" - просто поисковик по некоторым собранным данным Или какие-то "конструкторы запросов" в приложении. Так же, надо заметить, что например западные системы типа OeBS (Oracle Forms, OAF, ADF), тоже себе вполне QBE (Query By Example) поддерживают и считают, что это нужно и эффективно. 1) "труба, во-первых, для БД" - при "конструкторе запросов" и куче справочников - да, могут быть проблемы с неэффективными запросами, но это от прямоты рук программиста зависит. при QBE (например OeBS) проблем вроде нет, т.к. запрос QBE идет поверх основного запроса и только добавляет предикатов (повышает селективность). 2) "для разработчика" - у кого какой опыт. Такие инструментарии и нужны для того, что бы пользователь сам мог выполнять поиск (возможно не эффективно, но МОГ), а не хаял программу или не складывал маты на разработчиков. Пример в приложениях, где я такое видел: KAMIS - www dot kamis dot ru - Поиск сделан в виде дерева, примерно как у чччД. Работал все 90-е на FoxPro, все 2000-ые на Oracle Server и Oracle Forms. Сейчас не знаю. Проблемы с неэффективностью запросов/планами на Oracle были (на FoxPro таких проблем не было AFAIK), но решались автоматическим добавлением хинтов в генерируемый select. OeBS - Oracle Forms, Query By Example ==== Например КАМИС, не только учетная система (в учете там проблем с поиском нет), но и для фондовой работы. А что и когда потребуется найти в фондах - никто не знает и формализовать это не возможно. Значительно проще конечно искать в системах типа "сайт", но и конструктор запросов нормально работает. Когда в г.Рыбинск приезжал директорор Эрмитажа, директор Рыбинского музея в качестве примера "работы системы" за 5 сек. нашел все предметы из Эрмитажа которые хоть раз в жизни передавались на выставку в Рыбинск. (т.е. поиск через 2-3 справочка/таблицы связок). Понятно, что это редко требуется. Обычно банальный поиск по номерам КП,Инв,ВХ, автору, названию и еще паре полей (в зависимости от фонда) но иногда требуется и сложные варианты поиска, в том числе, по полям в справочниках. А тут без некоего конструктора просто никак. К примеру если есть какой нибудь "спонсор" из Италии, вполне может потребоваться найти все картины написанные в 1920-1940 гг. художниками родившимися в Италии. Т.е. искать нужно как по таблице предметов, так и по справочникам AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 11:54 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevMasterZivЕсли пользователи начинают писать запросы.... Никто не говорит, что он будет писать SQL. Но я знаю целый ряд задач, где поиск нужен крайне не формализованный. Наверное, такое бывает редко, но формализовать не возможно.Единственный случай удачной системы поиска который я знаю это поиск чрезвычайно привязанный к конкретной задаче. Чем меньше универсальности, тем лучше. Универсальность хороша для нас (разработчиков), но жутко сбивает с толку юзеров. Чем сильнее система поиска привязана к месту - тем для юзера лучше. Ни одна система фильтрования, что я видел, не выдерживает проверкой юзерами. Причина в том, что все эти фильтры основаны на формальной логике, а большинство юзеров просто не привыкло задумываться о "и" и "или". То что показал чччД это довольно удачное решение для быстрого рисования запросов, но человек не привыкший к формализованию своих мыслей не сможет в этом дереве разобраться. Построитель запросов типа того что в Акцессе имеет больше шансов, там WYSIWYG более нагляден, но подобная штука довольно напряжна для БД и клиента - первый то запрос вынужден дать гигантский объем данных, прежде чем юзер сообразит что надо отфильтровать. Юзера понимают таблицу (не обязательно Эксель, но обязательно таблица). Вот есть разлинованное нечто, в нем есть идентификаторы клиентов, надо добавить в это разлинованное нечто какие-то неконкретные данные из базы данных. Собственно говоря это и есть ТЗ для самой удачной self-serve reporting system. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 17:32 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
White Owl...не выдерживает проверкой юзерами. Причина в том, что все эти фильтры основаны на формальной логике, а большинство юзеров просто не привыкло задумываться о "и" и "или". То что показал чччД это довольно удачное решение для быстрого рисования запросов, но человек не привыкший к формализованию своих мыслей не сможет в этом дереве разобраться. ... As far as I know. Ссылку на сайт системы (www.kamis.ru), где такое используется и "выдержало проверку временем" (>15-20 лет) привел. Насколько пользователи (гуманитарии) привыкли к формализованию своих мыслей - не знаю. Такой статистикой не располагаю. Если особо интересно, можно обратиться к разработчикам системы Директор музея вполне в построителе запросов разбирался и проблем у него не возникало (выше приведенная байка из реальной жизни). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 17:41 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Посмотрел сайт. Сейчас новая версия (КАМИС 5), но построить запросов остался. В файле "Что нового в КАМИС 5" на 3-ей странице описывается собственно построитель запросов. Т.ч. over 3-и разные версии (FoxPro /KAMIS, 3.0/, Oracle Forms /KAMIS 2000/, Kamis 5), 20-25 лет. Такая "проверка временем" ))) http://www.kamis.ru/aboutsys/docs/ As Far As I Know ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 17:47 |
|
||
|
Редактор логических выражений.
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev... Директор музея вполне в построителе запросов разбирался и проблем у него не возникало (выше приведенная байка из реальной жизни). Поставил себе отметку. Буду знать, что где-то есть такой пользователь. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 19:58 |
|
||
|
|
start [/forum/topic.php?fid=57&msg=39191234&tid=2018581]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 17ms |
| total: | 153ms |
| 0 / 0 |
