Странное ТЗ: GUI для создания SQL-запроса во все стороны:)

Дали писать прогу для управления кадрами (регистрация сотрудника + все операции с сотрудниками + отчеты)
Но есть дополнение: "Создай такую форму, чтоб можно было любые запросы по выбору данных из таблицы делать и выводить на экран... Ну то есть если я хочу ВЫБРАТЬ ВСЁ ИЗ таблицы "Сотрудники" ГДЕ "Должность"="Сварщег" А "Фамилия" ПОХОЖА_НА "Иваноф" - чтоб это присутствовало".

Я со злости хотел пустую текстовую строку оставить, мол пусть вводят SQL запрос какой хотят
И все таки, как лучше оформить форму формального запроса в БД, если изначально не знаешь, как этот запрос будет выглядеть?

PS.: прогой будет пользоваться фиг знает кто и он точно не знает SQL.

 

1)
Ну можно командой SHOW получать список полей таблицы (если они могу поменяться), формировать список полей и для каждого рядом combobox с операторами (равно, похоже(LIKE ??), больше, меньше ну и т.п.). Соответственно между полями combobox'ы с логическими операторами.
2)
Проще для пользователей, но хуже в программировании. Поле ввода запроса на более-менее естественном языке с небольшим ассоциативным массивом "слово" => "оператор SQL". В принципе, если продумать команды, составить хороший ассоциативный массив и ввести приемлемые ограничения, то неплохо получится.

 

Код (Text):

1. [Должность] [И] [Фамилия]
2. [равно]             [похоже]
3. ["Сварщег"]       ["Иваноф"]

Если ПОХОЖЕ НА допускает искаженное название, то тут уже выборка всех записей данного поля и отбор в программе.

 

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

 

device
В MS Access посмотри конструктор запросов. Весьма интересная штучка.

 

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

 

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

Кстати, вопрос не в тему: А за сколько дней возможно написать такую прогу? (все включено: Отчеты, база, рег формы, выбор...) Я за неделю только описал (и то не до конца) основные классы (Сотрудник, Отдел, etc,, Фабрика Сотрудников (OfficerFactory) ) плюс GUI для форм регистрации. А то требуют уже...

 

Twister

Ну отчего же не вариант - у нас многие пользователи (которые вообще SQL не знают) конструируют достаточно сложные запросы к базе.

 

Это общий вид рег формы


а вот это - форма выбора... тут задача, собственно.

 

А если строить И/ИЛИ дерево, где корень - запрос в целом, а узлы и листья - операторы над полями либо над узлами более низкого уровня? Сразу и внешне понятно, и SQL-запрос очень легко сформировать по данному дереву.

А насчет варианта с таблицей. Три строки и колонок по числу составляющих запроса. Минус - вложенные и сложно-составные запросы сделать не получится, ИМХО. А вот с И/ИЛИ деревом можно любую вложенность и сложность.

 

device
А в чем проблема - то?
Ну есть у тебя таблица с определенным набором столбцов. Тебе нужно произвести поиск по ней, причем запрос может быть разным.
Создай формочку, где нарисуй поля ввода по которым будет поск. На основании пустое поле или нет формируй запрос.
Насчет похоже... Ну создай для каждого доп опцию - "найти похожее". И ищи совпадения от трех допустим символов в любой позиции строки.
Иваноф - обсуди насколько должно быть похоже. Сколько несовпадающих символов допускаются 1, 2. Думаю больше двух смысла нет. Ну и используй строковые функции или регулярные выражения для окончательного отбора.

 

vito
А как он должен будет делать запросы вида "Выбрать всех, у кого зарплата выше средней" таким вариантом GUI?

Либо "Самый молодой сотрудник отдела Кашеварения и начальник отдела Кашеварения". В общем вложенные ( WHERE id = SELECT ) и сложные ( WHERE (a=2 AND b=3) OR (a=3 AND b=2) ).

А "похожесть" только на клиентской стороне, LIKE не поможет. И тогда просто простым посимвольным сравнением или XOR в case-insensitive.

 

Xerx
Я не знаю какю БД они используют. У всех возможности разные.
Но очевидно окончательный отбор лучше сделать на клиентской стороне. Хотя... я не думаю что там миллионы сотрудников.
Собственно это задача - страховка от опечаток. Мне так думается. Там верно будут работать настоящий дойчен инжинеер

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

 

vito
Да нет, автор написал, что нужно выполнять любые запросы к БД. Вот от этого я и отталкиваюсь. В общем ждем, что он напишет.

 

SQL Community Server

Для кадров - там человек 20 будет сидеть, а потом нужна будет база по контрагентам с подсчетом идексов закрытия торговых операций. Там - тысячи клиентов.

Это так, LIKE ищет только совпадения в начале или середине (LIKE %строка или LIKE %строка% или LIKE строка%)
А если написать интерпретатор SQL на русском....
То есть Юзер сделает запрос "ВЫБРАТЬ * ИЗ СОТРУДНИКИ ГДЕ .....<данные, условия.....>"
хотя... имхо это КГ/АМ

Это и есть проблема. Это нужно организовать.

Я думаю вот что. Надо описать структуру UserOperations (пользовательские операции). Структура будет с линками к описателям отдельных операций. Задача будет состоять в том, что в данный момент хочет пользователь, и поиск решения на основе полученных данных.

 

Вот я и предлагаю дать пользователю возможность построить дерево запроса. Функционально оно позволит выполнить произвольный запрос, а потом по готовому дереву просто пройтись и сформировать SQL-запрос. В плане его формирования стоит посмотреть на Visio.

Ну и наконец

. Мне это импонирует значительно больше всех остальных вариантов, особенно если во время ввода будет контекстная справка (ввел "Сот", он тебе предложил "Сотрудники" и "Сотовый"). В принципе реализовать достаточно просто - главное набрать базу русскоязычный аналогов команд SQL. Просто дать попользоваться людям пару часов с ведением лога их запросов. А затем сформировать конечный автомат/контекстный анализатор/линейный парсер. Если, как я уже писал, ввести разумные ограничения на команды ("дай-ка мне..." позволять, а "ей, ты, дай сюды это, как его..." блокировать ), то вполне хватит достаточно небольшой базы.

 

Xerx
Интерпретатор написать достаточно просто... Я даже могу с подсветкой синтаксиса.
Контекстная справка - в виде объекта Window, окна, которое не регистрируется в оконном менеджере, а в окне список (List) с вариантами. Crtl+<пробел> вызывает окно. Также можно встроить операции (+, -, =, NOT, OR, AND, XOR). Запросы можно сохранять в виде опкодов. По байту на каждую операцию.
НО ВОТ ВОПРОС: А будут ли юзеры с этим работать? Удобно ли это?
Или меня пошлют?

[offtop]
Отпишите плиз русскоязычный туториал по разработке макросов для FASM. Мне надо создать модуль для cвязи FASM с APT (AnnotationTypeProcessor и AnnotationTypeCompiler), если это удастся, можно будет создавать удивительнейшие вещи на fasm
Я хочу попробовать написать рефлектор для объектов, хранимых в базе данных
Этакая кроссплатформенная реализация Persistence на фасм.
[/offtop]

 

device

1. Попробуй пообщаться с "самыми продвинутыми".
2. Если не получится, пообщайся с их начальством - если начальство прикажет, юзеры "будут довольны".

 

device
crypto правильно говорит - нужно отталкиваться от знания и пожеланий конечного пользователя/начальства. Тут главная проблема - скорость набора - вряд ли многим проще будет набрать, чем мышкой потыкать. Следовательно и нужно вводить контекстную справку, стандартные шаблоны(типовые запросы) и т.п.

Если мне не изменяет память, то окно, имеющее родителем НЕ рабочий стол (ну и еще несколько стилей) не выводится в Диспетчере. Либо я неправильно понял значение понятия "оконный менеджер".

 

А чем LIKE не устраивает ?