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

← →
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]

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

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

← →
Kolan © (2008-04-02 11:42) [57]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

← →
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]
> Еще есть пользовательская настройка встроенная в контекстное
> меню для регистронезависимого поиска и поиска по неполному
> вхождению.
> устанавливается и запоминается для конкретного экземпляра
> грида в приложении.

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

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

← →
Игорь Шевченко © (2008-04-02 12:28) [67]

> а) таблицы от 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]

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

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