Шаблоны или идеи для веб-ориентированного доменного конструктора запросов (не для отчетов)?

Question

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

Ситуация такова, что у нас есть база данных, которая содержит все виды данных о большом списке проектов. Существуют десятки таблиц, которые предоставляют вспомогательную информацию о проекте, как в формате 1: 1, где некоторый конкретный тип информации о проектах (скажем, ProjectInfoTypeA) может храниться в таблице с именем ProjectInfoTypeA, и мы выполняем внутреннее соединение между ним и таблицей проектов, а также от 1 до многих, например, ProjectScopeKeywords, где проекту может быть назначено N атрибутов или, в данном случае, «ключевые слова» для ряда различных таблиц атрибутов / подстановок.

В конце концов, нам нужно, чтобы пользователь нашего веб-приложения создавал такие вещи, как: Покажите мне все проекты, выполненные за последние 5 лет, на выполнение которых ушло не менее 4 лет, стоимость не менее 1 млн. Долл. США и все 3 из этих ключевых слов (x, y, z) связаны с ним.

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

Как только мы получим список проектов из их фильтра, нам нужно будет работать с ним разными способами, но не в виде отчета. Если бы это был отчет, я бы просто дал им какой-нибудь конструктор отчетов, но нам нужно поработать с их отфильтрованным списком в веб-приложении.

В настоящее время мы думаем о двух разных идеях: 1) мы просто пытаемся написать собственный пользовательский интерфейс для построения запроса, а затем создать гигантский оператор SQL.

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

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

Answer 1

Я бы порекомендовал выбрать вариант 1. Я использовал подход к построению запросов в ряде проектов с различной степенью сложности в зависимости от сложности требований.

Если вы можете использовать готовое решение, вы можете найти несколько в Интернете: http://www.google.com/search?q=sql+query+builder

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

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