несколько запросов

← →
Armond © (2008-04-02 08:59) [0]

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

← →
Sergey13 © (2008-04-02 09:03) [1]

Оформить первоначальный запрос в виде подзапроса.
Или фильтровать данные локально на клиенте.

← →
Armond © (2008-04-02 09:21) [2]

> Или фильтровать данные локально на клиенте.

Попробовал так, но он все равно берет весь набор данных

← →
Sergey13 © (2008-04-02 09:25) [3]

> [2] Armond © (02.04.08 09:21)

Значит наверное неправильно пробовал. Или есть еще варианты?

← →
Armond © (2008-04-02 09:27) [4]

Вариантов нет, может подскажешь как грамотно и правильно справиться с такой задачкой ?

← →
Kolan © (2008-04-02 09:28) [5]

Тебе же ответили в [1]. Какие вопросы осталсь?

← →
Sergey13 © (2008-04-02 09:32) [6]

> [4] Armond © (02.04.08 09:27)

Так как же я тебе что-то подскажу, если я НИЧЕГО не знаю о твоей проблеме?

← →
ANB (2008-04-02 09:35) [7]

> но уже из того набора данных, который уже выбрали !!

ИМХО : плохо продумано решение. Для клиент-серверных систем - совершенно неудачная задумка. Не имеет смысла выбирать сначала кучу, а потом уже из нее выбирать кусочек.

← →
Kolan © (2008-04-02 09:39) [8]

> [7] ANB (02.04.08 09:35)

Ну почему, может он хочет фильтр сделать&#133

← →
Armond © (2008-04-02 09:50) [9]

Ну можно фильтр, можно запросы, но надо чтобы не из общего набора данных выбиралось, а уже из выбранного

← →
Reindeer Moss Eater © (2008-04-02 10:00) [10]

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

← →
Игорь Шевченко © (2008-04-02 10:01) [11]

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

Стандартными средствами нельзя.

← →
Kolan © (2008-04-02 10:01) [12]

Что за компоненты ты используешь?

← →
ANB (2008-04-02 10:08) [13]

Компоненты - это вторично. Мы ничего не знаем про СУБД.

> Стандартными средствами нельзя.

Мона и довольно тривиально.
1) под первый набор данных завести таблицу (мона временную).
2) insert into tmp_table1 select . . .
3) Показать первую выборку - select * from tmp_table1
4) Если понадобилось - сделать выборку из первой выборки
select * from tmp_table1 where . . .

Тока для такого извращения нужны серьезные основания.

← →
Reindeer Moss Eater © (2008-04-02 10:10) [14]

Это то же самое как если у первому запросу добавить условие в where и повторно выполнить запрос на сервере.
то есть не то что он хочет.

← →
Armond © (2008-04-02 10:16) [15]

> Компоненты - это вторично. Мы ничего не знаем про СУБД.

Использую MS SQL, компоненты ADO

← →
ANB (2008-04-02 10:16) [16]

> то есть не то что он хочет.

Именно то. :)

Иногда приходится применять такой способ.
Классика - основной запрос довольно тяжел и доп условия совсем ломают план (да и на кажный чих замучаешься оптимизить). А к первой выборке юзеры хотят обратиться и так и эдак. Вобщем, почти олап получается :)

← →
ANB (2008-04-02 10:19) [17]

> Использую MS SQL, компоненты ADO

Тады читай 13. Но примеров не дам, т.к. с мс скл не работаю.

ЗЫ. Хотя чисто принципиально ИШ прав. Из набора данных сделать выборку еще раз стандартными средствами невозможно. Приведенный мной способ - лишь иммитация этого.

← →
Reindeer Moss Eater © (2008-04-02 10:20) [18]

нестандартное средство:
выполняем первый запрос, получаем датасет.
превращаем его в xml датапакет.
делаем по нему запрос икспасом, получаем список нодов.
трансформируем их в новый дата пакет и грузим в клиент датасет, получаем новый надор данных.

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

← →
Kolan © (2008-04-02 10:26) [19]

> Использую MS SQL, компоненты ADO

Очень даже не вторично. Смотри свойство Filter.
Specifies the text of the current filter for a recordset.

← →
Reindeer Moss Eater © (2008-04-02 10:28) [20]

Это даже не третично.

TDataSet
property Filter: string;

← →
Kolan © (2008-04-02 10:30) [21]

> Это даже не третично.

Перепутал Filter c Sort. Sort не везде есть.

← →
Игорь Шевченко © (2008-04-02 10:33) [22]

> вообще динамическая серверная фильтрация через клиентский
> грид

Удавиться. Бедный сервер.

← →
ANB (2008-04-02 10:36) [23]

> или вообще динамическая серверная фильтрация через клиентский
> грид (по типу грида в Ehlib)

Это как ?

← →
Kolan © (2008-04-02 10:40) [24]

> Это как ?

Как как, при каждом чихе делать новый запрос (добавляе WHERE) и делать новую выборку&#133

← →
ANB (2008-04-02 10:42) [25]

> Kolan © (02.04.08 10:40) [24]

И при чем тут грид ? Это и без грида мона забацать

← →
Kolan © (2008-04-02 10:43) [26]

> Это и без грида мона забацать

ЭхГрид это умеет делать сам&#133

← →
Armond © (2008-04-02 10:43) [27]

> Это и без грида мона забацать

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

← →
Kolan © (2008-04-02 10:44) [28]

Наверно Reindeer Moss Eater говорил о сортировке при клике на название колонки ил о чем-то подобном&#133

← →
Kolan © (2008-04-02 10:44) [29]

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

Ты что глухой? Используй свойство Filter.

← →
Reindeer Moss Eater © (2008-04-02 10:45) [30]

все можно. можно и кверианалайзер всем раздать

← →
Reindeer Moss Eater © (2008-04-02 10:46) [31]

Наверно Reindeer Moss Eater говорил о сортировке при клике на название колонки ил о чем-то подобном…

Когда Reindeer Moss Eater говорит о сортировке, он говорит о сортировке.
А когда Reindeer Moss Eater говорит о фильтрации, он говорит о фильтрации.

← →
Reindeer Moss Eater © (2008-04-02 10:47) [32]

Удавиться. Бедный сервер.

<Цитата>

Жалко что сотни серверов об этом много лет ничего не знают.
А то действительно удавились бы.

← →
Kolan © (2008-04-02 10:49) [33]

> Когда Reindeer Moss Eater говорит

Тогда как выглядит фильтрация с помощью грида?

← →
Reindeer Moss Eater © (2008-04-02 10:51) [34]

Грид лишь интерфейсное средство, дающее возможность юзеру неискушенному в sql получить то что он хочет, причем без дурацких мастеров, визардов и прочих конструкторов запросов.

а сама фильтрация делается запросами.

← →
Kolan © (2008-04-02 10:52) [35]

> Грид лишь интерфейсное средство

Ну вот я и не понимаю как в плане УИ можно используя грид сделать фильтрацию&#133

← →
Sergey13 © (2008-04-02 10:56) [36]

> [35] Kolan © (02.04.08 10:52)
> Ну вот я и не понимаю как в плане УИ можно используя грид
> сделать фильтрацию…

Так же как и сортировку. Посмотри ЕхЛиб - там реализовано и то и другое. Естественно через датасет.

← →
Reindeer Moss Eater © (2008-04-02 10:56) [37]

Удавиться. Бедный сервер.

Кроме "бедных серверов" в мире еще есть не менее "бедные" каналы.

Что вы взамен моего примера предложите юзеру для поиска записи из большой таблицы?

локальный локейт?
локальный фильтр?
вводить маску поиска в едит и выполнять запрос пока юзер не угадает правильное слово?

← →
Kolan © (2008-04-02 11:00) [38]

> Кроме «бедных серверов» в мире еще есть не менее «бедные»
> каналы.

Что то я не понял. Так ведь каналу тоже худо. Допустим фильтрую по фамили. Обычно в начале пользователь видет все данные. А потом только их фидлитрует.

Твой вариант:
1. Станули весь набор.
2. Пользователь ввел первую букву фамилии  Станули всех начинающихся на эту букву.
3. Пользователь ввел вторую букву фамилии  &#133 итд.

Вариант с локальным филтром.
1. Станули весь набор.

Все. Где же в варианте 1 выигрыш для канала?

← →
Игорь Шевченко © (2008-04-02 11:03) [39]

Reindeer Moss Eater © (02.04.08 10:56) [37]

> Что вы взамен моего примера предложите юзеру для поиска
> записи из большой таблицы?

От задачи зависит. Я в своей жизни еще не встречал задачи "поиск неизвестной записи в большой таблице"

← →
Reindeer Moss Eater © (2008-04-02 11:05) [40]

В моем варианте весь набор вовсе не тянется. И не перетягивается после ввода каждого очередного символа.
А вот тебе, чтобы найти что-то локальным фильтром придется все засосать на клиента.

← →
Kolan © (2008-04-02 11:06) [41]

> В моем варианте весь набор вовсе не тянется. И не перетягивается
> после ввода каждого очередного символа.

Ну а как тогда, объясни, может я полезное что-то узнаю.

← →
Reindeer Moss Eater © (2008-04-02 11:07) [42]

От задачи зависит. Я в своей жизни еще не встречал задачи "поиск неизвестной записи в большой таблице"

Ну я не про жизненный опыт и спрашивал, а про альтернативы.

← →
Reindeer Moss Eater © (2008-04-02 11:10) [43]

Ну а как тогда, объясни, может я полезное что-то узнаю.

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

← →
Игорь Шевченко © (2008-04-02 11:13) [44]

Reindeer Moss Eater © (02.04.08 11:07) [42]

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

← →
Armond © (2008-04-02 11:15) [45]

Да понимаете народ, у меня есть таблица, есть 5 комбобоксов, т.е. максимум может быть 5 фильтров, не более. Например, клякнули по первому комбобоксу, отсортировали по данные, потом может быть больше и не надо, а может наоборот, придется и по другим сортировать !!! Вот такая вот задачка. Я вот думаю, может быть ввести данные по все комбобоксам, а потом нажать на кнопку и отработать один запрос. Хотя это наверное неправильно, да и запрос как такой большой построить ?

← →
Kolan © (2008-04-02 11:16) [46]

> В шапке грида в колонке открывается инплейс эдитор.

То есть ты показываешь человеку пустой грид.
Дальше он вводит что-то и только тогда показываешь результат?

Большинство пользоваетлей что я знаю (и я в том числе) начили бы орать: «ААА ве мои данные пропали».
Как можно фильтровать то, незнаю что. Может я вообще фильтроват не буду, а нужное мне и так видно.

А то что ты описал похоже на поиск.

← →
Игорь Шевченко © (2008-04-02 11:17) [47]

Reindeer Moss Eater © (02.04.08 11:07) [42]

Я, разумеется, в своем посте [44] имею в виду задачи OLTP, ибо делать OLAP на медленных каналах, по-моему, садомазохизм.

← →
Reindeer Moss Eater © (2008-04-02 11:19) [48]

То есть ты показываешь человеку пустой грид.

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

← →
Armond © (2008-04-02 11:20) [49]

> То есть ты показываешь человеку пустой грид.
> Дальше он вводит что-то и только тогда показываешь результат?
>

Нет, сначала у меня вываливаются все данные, действительно, я могу и не сортировать !!!

← →
Kolan © (2008-04-02 11:22) [50]

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

Дак откуда они беруться то?

Если с одной стороны «В моем варианте весь набор вовсе не тянется.», а с другой «В шапке грида в колонке открывается инплейс эдитор.».

То есть при показе грида ты все не тянешь, а задать условие можно только увидев грид. Что-то ты не договариваешь&#133

← →
Kolan © (2008-04-02 11:23) [51]

Удалено модератором
Примечание: Флудить завязываем

← →
Reindeer Moss Eater © (2008-04-02 11:24) [52]

Если с одной стороны «В моем варианте весь набор вовсе не тянется.»,

Включи скл монитор и посмотри чего и сколько будет зафетчено по сети при открытии запроса без where.

← →
Kolan © (2008-04-02 11:30) [53]

Понял наконец, ты хочешь сказать, что тянеш только видимую часть, так?

← →
ANB (2008-04-02 11:36) [54]

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

← →
Armond © (2008-04-02 11:38) [55]

> Самый хреновый вариант - когда юзер таки не знает, что именно
> ему надо.

> [45]

← →
Reindeer Moss Eater © (2008-04-02 11:41) [56]

АНБ - те же тестикулы, только сбоку.

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

> Типа  хочу все увидеть и глазками выбрать.

Это не самый хреновый вариант. А очень удобный и распространенный для небольших наборов данных. Для больших, согласен, нужно фильтороват, сортировать, делать пэйджинг, &#133 до.

← →
ANB (2008-04-02 11:42) [58]

> Хотя это наверное неправильно, да и запрос как такой большой
> построить ?

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

← →
ANB (2008-04-02 11:47) [59]

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

Как правило :
1) юзер путается в интерфейсе базового компонента
2) возможностей задавать фильтры у базового компонента довольно ограничены, особливо для всяких перечислений и ссылок на справочники, а так же сложных комплексных условий. В форме мона ввести обычный чекбокс и в обработчике извращаться
3) Хорошая запросная система пишется довольно долго и стоит немалых бабок. Я видел только одну, достаточно мощную и понятную для юзера. Ее писали 2 года и лет 5 отлаживали и шлифовали.

Как правило :
1) юзер путается в интерфейсе базового компонента
2) возможностей задавать фильтры у базового компонента довольно ограничены, особливо для всяких перечислений и ссылок на справочники, а так же сложных комплексных условий. В форме мона ввести обычный чекбокс и в обработчике извращаться
3) Хорошая запросная система пишется довольно долго и стоит немалых бабок. Я видел только одну, достаточно мощную и понятную для юзера. Ее писали 2 года и лет 5 отлаживали и шлифовали.

1. не более, а менее чем в мастерах и визардах
2. ограничены возможности и у отдельной формы. по справочникам (объединениям и вычислимым на сервере полям) поиск поддерживается если сервер умеет делать select from select
3. ну да. только в моем случае она есть всегда, хоть и не навороченная.

А чем так непонятно для юзера ввести маску поиска в заголовке колонки?
там ведь не просто банальные литералы но и вырадения поддерживаются
"больше" "меньше" "не равно" и тд.

← →
ANB (2008-04-02 12:02) [61]

> "больше" "меньше" "не равно" и тд.

"И" "ИЛИ" "НЕТ" . . .

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

Хотя мы спорим ни о чем. Оба варианта имеют право на жизнь. Единственно - я предпочитаю управлять процессом формирования текста запроса, независимо от интерфейса ввода оного. Т.к. в дальнейшем как правило вылезает задача оптимизации.

"И" "ИЛИ" "НЕТ" . . .

В базовом гриде EhLib есть только И по колонкам.
Я отнаследовался от него и у меня есть фильтрация и по ИЛИ.
Можно в фильтр добавить запись по PK, или по значению в любой колонке данных.
То есть данные введенные в шапке объединяются по "и", а горячие кнопки в области данных объединены по "или"

плюс есть инверсия условий для "НЕТ"

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

← →
ANB (2008-04-02 12:19) [65]

> Reindeer Moss Eater © (02.04.08 12:10) [62]
> "И" "ИЛИ" "НЕТ" . . .
>
> В базовом гриде EhLib есть только И по колонкам.
> Я отнаследовался от него и у меня есть фильтрация и по ИЛИ.
>
> Можно в фильтр добавить запись по PK, или по значению в
> любой колонке данных.
> То есть данные введенные в шапке объединяются по "и", а
> горячие кнопки в области данных объединены по "или"

И получаем фактически мастера для запросов :)

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

К сожалению, такое решение никак нельзя предлагать как универсальное для всех случаев жизни.

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

← →
ANB (2008-04-02 12:23) [66]

> Reindeer Moss Eater © (02.04.08 12:14) [64]
> Еще есть пользовательская настройка встроенная в контекстное
> меню для регистронезависимого поиска и поиска по неполному
> вхождению.
> устанавливается и запоминается для конкретного экземпляра
> грида в приложении.

Млин, ну совсем круто :)
Да еще и на базе моего любимого эхлиба ! (Ну не нравится мне девэкспресс, хоть убейся).

Раз уж так расхвастался - то делись сырцами :)

> а) таблицы от 15 миллионов записей

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

← →
ANB (2008-04-02 12:35) [68]

> у одного из наших заказчиков одна из основных таблиц - это
> сотни миллионов записей

Не, таких у нас не больше десятка наберется. В основном стараемся переносить старые данные в архив. Как правило приходится работать с таблицами от 5 до 50 миллионов. Юзера, заявившего, что хочет выбирать ручками, не увольняют. Просто ему выдают порциями без сортировки все записи по 50 в порции. С задержкой в выдаче кажной порции около минуты. Пусть смотрит. Сервак даже не чихает. Обычно через неделю он заказывает нормальный фильтр. :)

Ну я тоже на натравливаю втупую в таких ситуациях этот грид с "селект все фром все"

> Armond (02.04.2008 9:50:09) [9]

Используй AND

> Kolan (02.04.2008 10:30:21) [21]

> Sort не везде есть.

Filter тоже не везде есть.

> ANB (02.04.2008 11:36:54) [54]

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

> ANB (02.04.2008 11:42:58) [58]

А почему не 256 мегабайт? База была озвучена? Но и 64 кб много, это примерно 1000 строк кода, это мелкий запрос.

> ANB (02.04.2008 12:19:05) [65]

А не окажется ли потом, что у пользователя вся форма кнопками заполнена, не придется ли делать иерархию форм, а потом иерархию иерархий

> Игорь Шевченко (02.04.2008 12:28:07) [67]

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

> ANB (02.04.2008 12:35:08) [68]

Надеюсь кнопку Прекратить ему не выдают? А за аварийное окончание программы бьют по почкам?
Ну не может фирма быть благотворительным учреждением, содержать ненужных работников, правильнее нанять нормального работника.

Anatoly Podgoretsky © (02.04.08 20:33) [75]

Да заказчик он тоже несильно благотворительностью занимается :) Ему от бестолковых работников профиту немного.

Anatoly Podgoretsky © (02.04.08 20:33) [75]

> При том у тебя малекая табличка, надо на несколько десятков
> миллиардов.

На такое количество самолетам керосина не хватит

> Игорь Шевченко (02.04.2008 20:44:18) [78]

Так вы наверно керосин в тоннах меряяте, а надо в литрах.

несколько запросов Найти похожие ветки