"Если вернулись к избитой теме, значит она еще не добита" (с)

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

Предположим скачал ты справочник на клиента. Как ты себе представляешь процесс его редактирования? Чисто технически. Напомню, что именно тебе надо сделать:

-) Изменить данные на сервере
-) Изменить данные на том клиенте, который вносил эти изменения (во временной таблице)

Зачем надо еще и на клиенте менять? А ты представляешь реакцию пользователя? Я данные изменил, а они не изменились! И объясни ему, что это разные таблицы!

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

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

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

Для начала, оценим объем данных, которые надо скачать. Ты уже писал, что минимальная длина одной записи 54 байта (4 байта - код, 50 байт - название). На 1 тысячу записей - примерно 50КБ. Это много или мало?

В абсолютных величинах так сразу и не скажешь.

Тогда поставь вопрос по другому: для чего нужен этот справочник в данном месте? Т.е. какой именно документ мы создаем (изменяем)? А теперь посмотри, какой объем данных (без собственно справочника) надо закачать с сервера, чтобы отобразить этот самый документ? Как этот объем соотноситься с объемом справочника? Подозреваю, что эти величины окажуться сопоставимы.

Кроме всего прочего, такие большие справочники (несколько тысяч записей), как правило, структурируют. Т.е. создают некую древовидную структуру. Хотя бы 2...3 уровня. Просто чтобы проще было найти нужную запись в такой "немерянной" куче. Или же организуют специальные фильтры (хотя бы по первой букве), чтобы закачивать не весь справочник, а только нужный пользователю фрагмент.

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

Понятно, что из справочника довольно тяжело вытащить именно то, что нужно "в данный момент". Но вовсе не потому, почему ты думаешь. Вспомни, как ты вытаскиваешь нужный документ (для просмотра или редактирования)? Неужели скачиваешь вообще все документы какие есть, а пользователь потом тупо листает всю эту кучу ища то, что нужно?

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

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

Первый скользкий момент:

ГенГрумЕсли взять в качестве примера справочник сотрудников, который изменяется раз в полгода – год.
Я не знаю, в какой именно конторе ты работаешь, но у нас принимают на работу/увольняют по несколько человек каждый месяц . Но даже если предположить, что в данный момент твой справочник действительно относительно статичен, то почему ты настолько уверен, что через пол-года - год ситуация не измениться самым кардинальным образом и у вас начнется бешенная текучка кадров?

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

Представь простую ситуацию: Один пользователь ввел новый элемент в справочник и создал документ с этим элементом. Далее другой пользователь открывает этот документ и не может найти элемент справочника. В его локальной копии такого нет.

Или обратная ситуация: один пользователь удалил элемент справочника, а другой - создал документ с его использованием. И что делать потом с таким документом?

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

И еще раз. Ты как-то совсем упустил из вида основной вопрос: А когда именно нужен весь справочник полностью? В какой момент?

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

ГенГрумСамое тяжелое в программировании – написать описание к программе
Нет, это второе по сложности. На первом месте - это тех.задание к программе. Именно с ним у тебя сейчас большие проблемы.

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

Как-то я видимо плохо объясняю.

Как работает клиент-сервер: Тебе нужно получить один документ и одну запись из справочника. Ты посылаешь запрос на сервер и он предоставляет тебе эту одну запись.

Все! В данном случае ВЕСЬ справочник НЕ НУЖЕН. Т.е. нет необходимости качать на клиента ВЕСЬ справочник.

Я все пытаюсь получить от тебя ответ, когда же реально на клиенте возникнет необходимость просканировать (отобразить) ВЕСЬ справочник. Иначе какой смысл держать его на клиенте? Уж скачивание одной-то записи справочника никак не перегрузит трафик.

Учти, что отображать несколько тысяч записей через ComboBox в принципе можно, но, боюсь, пользователи тебя прибьют за такой интерфейс.

Нет, ты опять не о том.

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

Более того, пользователь воспримет с пониманием, если подобный запрос будет выполняться относительно медленно.

Опираться на такие задачи как аргумент раздельного хранения данных крайне неразумно!

Насколько я понимаю, твоя конечная цель хранения справочника на клиенте это:

Уменьшение трафика

Ускорение отклика системы

Обе цели весьма сомнительны.

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

Для меня запросы к серверу деляться на 2 группы:


Когда пользователь с пониманием отнесется к задержке (спокойно подождет)

Когда пользователь не может ждать (начнет звонить и требовать подать сюда того программиста)

К первой группе относяться все задачи формирования отчетов (то, что ты привел в качестве примера) и, до некоторой степени, поиск нужных документов. И здесь +/- пару минут особой роли не играет.

Так что нет смысла экономить трафик только ради ускорения времени отклика. Причем еще не факт, что время уменьшиться, ведь надо еще "подвязать" полученную выборку к локальному справочнику.

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

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

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

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