Создание базы заказов с условиями отбора товара

← →
ruslanyd (2003-04-01 16:40) [0]

Народ, с 1 апреля всех! :)

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

Предусмотреть необходимо следующие:

1 возможности отбора :
=, <>, >, <
Null, not Null
отбор по контексту (только для строк)

2. на одно поле наложение нескольких условий

3. возможность обратного поиска, т.е. для такой-то записи
подобрать все запросы, которым удовлетворяет эта запись
Проблема именно в этом пункте, т.к. все варианты
хранения запроса, которые мне пришли в голову,
будут сильно тормозить :(

Вообщем, типичная задача для подбора товара по заказу
и подбора клиентов по имеющемуся товару

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

← →
Соловьев (2003-04-01 16:43) [1]

← →
ruslanyd (2003-04-01 16:49) [2]

неудачная шутка

← →
MsGuns (2003-04-01 16:50) [3]

Если делается что-то типа универсальной системы поиска (т.е. некая форма, на которой контролы для масок значений полей без привязки на контретные таблицы, то надо оперировать понятием "объект". Для них (объектов) сохранять-поднимать (к примеру из спец.Ini-файла) значения, а потом соотв. алгоритмом производить "шуршание" по БД.

← →
Yfhjl? c 1 fghtkz dct[! ^) (2003-04-01 17:07) [4]

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

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

← →
MsGuns (2003-04-01 17:17) [5]

>Yfhjl? c 1 fghtkz dct[! ^) (01.04.03 17:07) или как тебя там

Я так и не врубился, чего ты хо сделать ? Хранить параметрические запросы "где-то" в БД ? Строить из динамически из значений полей, которые тоже где-то хранятся ? Муть голубая или одно из двух ";))

Ты скажи мне, Русланчик, че те надо, че те надо,
Може дам я тебе то что хошь ;)))

← →
ruslanyd (2003-04-01 17:33) [6]

это имячко я случайно из буфера вставил, сорри :)

>Я так и не врубился, чего ты хо сделать ?
>Хранить параметрические запросы "где-то" в БД ?
именно, только запросы эти будут формироваться
при оформлении заказа и сам запрос будет представлять
из себя условия заказа

← →
MsGuns (2003-04-01 18:32) [7]

>ruslanyd (01.04.03 17:33)

Короче, делай так:
У тебя в модуле "Менеджер Запросов" (назовем это так, для краткости - МЗ) долен быть предусмотрен набор "болванок", т.е. комбинаций полей, в который юзер должон ввести свои значения. Ну, к примеру:
1. Запрос на допоставку
Поля:
<Поставщик>
<Группа товаров>
<Предельный запас на складе>
2. Запрос по задолженности
Поля:
<Поставщик>
<Пред.сумма задолженоости>
<Период приходов>

и т.д.

Все эти запросы ты хранишь в спец. объектах-контейнерах, которые загружаются по мере необходимости, к примеру, из текстового файла (я б делал TIniFile - удобно и можно если че ручками поправить). Объекты создашь как класс, нисходящий, например из TCollection. Каждый объект (запрос) содержит итемы (поля) со св-вами "Имя таблицы", "Имя поля", "Связка", "Ширина кол-ки грида", "граничные значения" и т.д. Кроме этого сам объект-запрос имеет свои, "родительские" св-ва: "Заголовок", "Пункт в меню", "Шаблон запроса" и т.д.

Юзеру МЗ дает меню, которое формируется динамически исходя из содержимого контейнера (который предв-но списком грузится из ini-файла). По выбору юзера на форму динамически кидаешь соотв.контролы типа TEdit и даешь ему их ввести. Потом опять же динамически создаешь SQL-запрос по описанию, хранящемуся в соотв.элементе контейнера (читаешь опять же ini, но уже "подробно") и запускаешь его. В гриде, настраиваемом динамически, отображаешь рез-ты поиска.

Если хочешь совсем круто (типа чтоб узер сам создавал запросы), напиши спец.конструктор, где бушь показывать структуры таблиц БД и связь между ними, проверять корректность и записывать в тот же ini-файл. Но я бы лично такую офигень делал бы только за ОЧЕНЬ хорошие бабки !

← →
ruslanyd (2003-04-01 19:30) [8]

С интерфейсной частью программы проблема не стоит
Это будет конструктор, но все будет гораздо проще:
юзверь выбирает то, что он хочет искать, откроется
стандартное для этой системы окно для поиска, состоящее всего
из трех основных элементов - список полей, к которым можно
применить условия поиска (загружается из базы или ini-файла),
условные операции (что-то вроде radio-buttons)
и создаваемый запрос

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

но я ушел от вопроса
как я уже говорил, проблема в том как хранить этот запрос в БД
и при этом обеспечить быстрый "обратный поиск",
который я описал выше

← →
MsGuns (2003-04-01 20:24) [9]

Создай подкаталог TovSQL там же, где и БД, и все запросы складывай/поднимай оттуда (SQL.SaveToFile/LoadFromFile)

И все недолга ! Не делать же спец. таблицу для хранения эскюэлей

← →
ruslanyd (2003-04-02 12:22) [10]

>И все недолга !
уже проверено - долго
прямой поиск выполняется, ессно, нормально
а обратный, который возвращает все запросы, удовлетворяющей заданной записи - неоправданно долго
это из-за того, что перед проверкой выполняется
парсинг каждого запроса

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

← →
MsGuns (2003-04-02 12:30) [11]

Я, наверное, чего-то недопонимаю ! Этих запросов что, сотни тысяч ? Т.е.хранятся не "болванки" а собственно готовые запросы с подставленными вариантами значений ?

← →
ruslanyd (2003-04-02 13:58) [12]

>Я, наверное, чего-то недопонимаю ! Этих запросов что, сотни тысяч ?
ну не сотни тысяч, но около пяти тысяч есть уже сейчас

>Т.е.хранятся не "болванки" а собственно готовые запросы
>с подставленными вариантами значений ?
допустим, я делаю такой запрос:
найти все объекты, у которых a=1 или a=2 и b<>"aaa"
в этом случае записываю в базу три записи:

IDзапроса поле условие значение
1432 a = 1
1432 a = 2
1432 b <> "aaa"

← →
ruslanyd (2003-04-02 14:11) [13]

вот я тормоз! :) кажись, я уже все придумал!
можно без проблем записывать все запросы в виде SQL
и в случае с обратным поиском можно почти всю работу
возложить на сервер БД
нужно только в WHERE первым добавить еще одно условие,
которое отбирает по превичному ключу проверяемой записи

и если такой запрос вернул эту запись, то мы нашли то что надо

Создание базы заказов с условиями отбора товара Найти похожие ветки