Навигация по большому объему данных или СПРАВОЧНИК

[Guard]

Имеется Firebird + Delphi 7 + FibPLus
таблица товаров на 15000 наименований + таблица цен для каждого объекта + таблица остатков по объектам + несколько других таблиц справочников(Ед.измерения, Поставщиков, Пользователей) всё это объединяется в единый справочник.

ПРОБЛЕМА
На Celerone 2200\512Mb вход в справочник 10 секунд, но передвижение по нему рывками и не устраивает заказчика.
Используемый в данный момент вариант - приём всех данных(Fetch All) на сторону клиента и обновление редактируемых записей( 30 секунд первоначальная загрузка и столько же при обновлении всего справочника).

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

Заранее благодарен всем откликнувшимся.

 

[Ognev]

Честно сказать, не очень понятна постановка вопроса. Если проблема в том, что выборка всех данных на клиента производится слишком медленно, то причем здесь интерфейс???

Что касается оптимизации, то можно идти разными путями. Например, оптимизировать структуру БД для уменьшения передаваемой информации на клиента. Передовать на клиента не всю информацию по каждой записи, а лишь самую необходимую. Но, конечно, оптимальной на мой взгляд (в умных книжках наверняка это пишут ) является предварительная фильтрация данных перед передачей на клиента. Никто и никогда не будет редактировать сразу 15 тысяч записей, более того, никто и никогда не будет их даже читать. Так что, фильтруй данные на уровне запросов, а не на уровне локально полученных на клиент данных. Тогда большая часть проблем снимется.

 

[Guard]

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

 

[Ognev]

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

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

 

[Guard]

Насчет суперкомпа, в данный момент у заказчика стоит сервером Pentium 4 3.2\1Gb результат ~16сек(пробовал Xeon 2.6\2Gb ~14сек)
А вот про набор условий и способы реализации и был собственно вопрос

 

[Skorp]

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

Присмотрись к справочникам в SQL версии 1С, а если быть точнее то к слайдеру на полосе прокрутки... в каком бы месте справочника ты не был - он всегда будет по середине. Многие начинают кричать, что это баг, но мы то знаем, что не надо получать все 15 (а я сталкивался и со 150 и более) тысяч записей на клиента, а достаточно только те, что влазят в экранную форму, и немного вверх и вниз, что бы просматривать без рывков можно было.

 

[Guard]

Присмотрись к справочникам в SQL версии 1С, а если быть точнее то к слайдеру на полосе прокрутки... в каком бы месте справочника ты не был - он всегда будет по середине. Многие начинают кричать, что это баг, но мы то знаем, что не надо получать все 15 (а я сталкивался и со 150 и более) тысяч записей на клиента, а достаточно только те, что влазят в экранную форму, и немного вверх и вниз, что бы просматривать без рывков можно было.

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

А по поводу < Чуть чуть вверх вниз > , ты рассматриваешь самый простой способ навигации - линейный. Когда сам компонент считывает себе в кеш несколько записей, но торможение появится потому, что обрашение к базе происходит только при достижении границ кеша(во всяком случае в стандартном GRIDe). Для избежания торможения нужен доступ в несколько потоков к базе.

Есть такой компонент gb_DataSets Components от Спирина Сергея
([email protected])
Вот в нем реализована приблизительно такая функциональность + индексы по убыванию возрастанию, но его поддержка вроде бы закончилась.

И потом, вопрос вообшем то о реализации интерфейса

 

[Skorp]

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

 

[Guard]

Ну жадный я жадный
Вопрос вообщем то был действительно про интерфейс потому, что кинуть на форму обычный GRID и подключить к нему компоненты доступа к базе вопрос вообщем то тривиальный. В том же 1С реализация локальной (на .dbf) и SQL(на MS SQL Server) ничем не отличается.
Мое мнение что в программах баз данных после перехода с локальных версий на SQL сервера интересно кроме изменения подхода к обработке данных разработать и интерфейс взаимодействия с пользователем на это ориентированный

 

[Ognev]

Guard,
для написания нормальных фильтров надо детально знать специфику той работы, для которой создана БД и сам софт. Всегда лишь стоит включить поиск по части названия (как реализовать, вопрос, видимо смешной - TEdit+TLable, например ). Остальное - сильно зависит от специфики, готовые универсальные решения трудно придумать. ... Или уточни вопрос, а то ощущение, что говорим о разных вещах

 

[Guard]

У меня разные фильтры, поиски, сортировки уже реализованны. Мне интересно Ваше мнение по поводу начального или полного т.е. без всяких фильтров отображения справочника.
Из моих мыслей - например показывать сначала панель фильтрации\сортировки\видимости колонок и потом формировать запрос, в котором возможно уже сократится не только число взвращаемых записей, но и уменьшится количество объединяемых таблиц. К сожалению данный метод не работает при просмотре полного справочника.

 

[Ognev]

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

 

[Guard]

У меня почти все это уже реализованно, кроме предварительного показа панели фильтрации и как раз данные и условия фильтрации разделены. Структура запроса пока не изменяется(собирался писать, но теперь наверное не буду. Спасибо)
Я так понимаю все эти способы довольно тривиальны для людей разбирающихся в базах. Как всегда хотелось чего-нибудь РЕВОЛЮЦИОННОГО.

 

[Ognev]

Не стоит стараться делать революционно, лучше делать удобно

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

Удачи!

 

[aktuba]

А поподробнее можно?

 

[Guard]

А поподробнее можно?

Вообще эта идея не нова, просто если грузить в дерево все данные сразу, то скорость относительно грида не увеличится, получится только иерархическое представление данных. Поэтому загружается только верхний уровень, а потомки подгружаются по мере необходимости. Этот вид представления данных, на мой взгляд хорош, если информацию можно разделить на относительно небольшие группы, соответственно если этого сделать нельзя, то смысла в дереве нет.
Для примера посмотри здесь http://www.ibase.ru/devinfo/treedb.htm

 

[i2s]

В конце концов, можно найти с заказчиком альтернативу, например давать возможность выбрать часть справочника по 1 букве (вывесить алфавит на кнопках), либо по каким то другим критериям. Естественно, таблица должна быть отиндексирована. Это ты хоть сделал?

 

[Guard]

В конце концов, можно найти с заказчиком альтернативу, например давать возможность выбрать часть справочника по 1 букве (вывесить алфавит на кнопках), либо по каким то другим критериям. Естественно, таблица должна быть отиндексирована. Это ты хоть сделал?

Если бы ты сначала почитал обсуждение, то ивидел в #3 я пишу :

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