Здравствуйте.

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

С Дельфи знаком на уровне синтакса :) , про разнообразие разных виджетов знаю еще меньше, но постепенно учусь.
Мой проект использует стандартные DB виджеты, плюс набор из DevExpress.

Описание проблемы, которую я решаю:
- в базе данных есть таблица на 20 тыс строк, которую я могу за пару секунд отобразить на экране в гриде, в режиме чтения
- я предпочитаю держать все данные в гриде, чтобы разрешить быстрый поиск по Ctrl-F и мгновенную сортировку по колонкам
- таблица в базе данных время от времени изменяется, не более одного 1% строк меняются за день.
- нужно синхронизировать данные, чтобы грид показывал измененные строчки, с задержкой не более нескольких секунд

Я знаю пару методов решения:
(1)- самый простой - перезаливать весь грид периодически. Это даст 2-секундные подвисания на клиенте, и нагрузит сервер и сеть.
(2)- ручные дельты - периодически запрашивать список изменений от известного состояния таблицы, править измененные строки

Надеюсь, что есть виджет который уже умеет такое делать, с минимальной нагрузкой на сервер.
Если такого нет и быть не может, остается вариант ручных дельт (2).

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

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

Изначально "показать всех" занимало до 20 секунд. Сейчас я снизил это до двух секунд за счет разных оптимизаций запроса, но теперь уже упираюсь в скорость заполнения грида строчками - это примерно две секунды при 100% одного ядра (медленные терминалы).
Я могу ускорить далее, если вместо разрушения/создания грида каждый раз буду просто прятать форму и показывать ее снова.
(хранение 20 тыс коротких строчек в памяти не создает проблем)

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

Спасибо за подсказку, я почитаю про UnboundMode.

Благодарю за дельный совет.

Собираюсь держать всю форму, чтоб выпрыгивал мгновенно по кнопке.

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

Постановка задачи разведочная. Поэтому "было бы удобно если есть"
Я в курсе некоторых основных технологий, но всего не знаю.

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

Думаю, что в 1990 кто-то самодовольно поучал других: "он хочет чтоб веб сервер к браузеру стучался, да он азов интернета не понимает".

Потом сделали, теперь я могу в Гугл докс таблицу редактировать одновременно с другими, все вживую и никакого поллинга.

Да, и ещё скорость света, гамма лучи и воля бога.
Мы тут не теоретической математикой занимаемся, а прикладные задачи решаем.

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

Чужая работа редко кажется важной :)

Я признаю что вопрос был поставлен узко, и без контекста.

Вот контекст, чтобы желающие могли поразить мозги.

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

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

10к строк/сек это ограничение грид-контроля в условиях маломощного ЦПУ. Чтобы делать быстрее, пришлось закэшировать форму. Теперь адресная книга выскакивает мгновенно, но в ней данные с прошлого раза.

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

Спасибо. Хотя я не смогу это использовать, было интересно узнать что СУБД развиваются в этом направлении.

Я опишу реакцию:

"Ой, телефон на одной строчке поменялся? Прямо на глазах! В точности как в демо, когда нам показывали в тренинге про улучшения в системе. Сейчас позвоню Аллочке что заметила ее правку живьем".

Корпоративная среда, все легко.

white_nigger,

Server mode - это на первый взгляд то, что нужно. Посмотрю в этом направлении, спасибо.

Мимопроходящий,

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

Это, имхо, не тот случай. Аутлук умеет мгновенно показать адресную книгу на 100+ тыс, поэтому "сделай адресную книгу как в аутлуке" это довольно резонное требование.

Внезапно, но - не может. Первый десяток адресов из этой книги - да, но чтобы все 100+ тыс...


Аутлук тянет корпоративную адресную книгу из локального кэша, который периодически обновляется в фоне. Помню что обновления в адресной книге аутлука 2000/exchange 5.5 запаздывали на минут 5-10, что резонно для справочника который редактируется извне.

Внезапно, но - не может. Первый десяток адресов из этой книги - да, но чтобы все 100+ тыс...


Аутлук тянет корпоративную адресную книгу из локального кэша, который периодически обновляется в фоне. Помню что обновления в адресной книге аутлука 2000/exchange 5.5 запаздывали на минут 5-10, что резонно для справочника который редактируется извне.

Ну так и ты показывай свой список из локального файла, который обновляй периодически. В
чём проблема-то?


У меня уже все в памяти и в гриде сидит, файл не нужен.

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

Если забылось:

> Я работаю над задачей, для реализации которой было бы удобно иметь таблицу на экране, которая авто-синхронизируется с таблицей данных