Доброго дня!
Приложение работает с БД, в базе имеется довольно много справочных данных. Для того что бы повторно не загружать их и уменьшить трафик, при старте загружаю все справиочники в QHash<int, QString> в одном единственном классе. Доступ получаю к ним через ф-ю QString valueById(int id), ну вместо value название справочника.
Так вот вопрос, правельный ли это подход, или лучше копировать QHash в новый объект? Вопрос в скорости работы и обращения к данным.

MasterZivНу и не понятно, как у вас все справочники грузятся в один QHash и почему у них в значении только одно поле и только строка.
Полей-то много бывает.
Спарвочники конечно же именование, и каждый я гружу в отдельй хеш, может я плохо объянил.
В базе храню последнее обновление каждого справочника, и проверяю по таймеру, и соотв. обновляю при необходимости.
Все эти справочники нужны только лишь в моделя представления, больше нигде. Т.е. в sql запросе я делаю минимальную выборку без join'ов и т.п. а в модели( наследую от QAbstractItemModel) использую как вывод текстовой инфы.
maytonЕсли у них справочники - append-only то можно их обновлять по факту "промаха".
Это как? Можете пояснить что такой "промах"?

Dimitry SibiryakovPS: По моему опыту, такое кэширование для экономии траффика - бесперспективняк. Проще
сервер БД поместить в локалку.
Это хорошо когда это можно сделать, но увы. А почему бесперспективно? Можно более развернутое пояснения вашей точки зрения?

egorychMasterZivпропущено...


Надо просто иметь возможность их всегда перечитать. В любой момент. Пользователю.
Ну или самому инвалидировать эти кэши, рассылая сообщения.два вопроса:
1. откуда пользователю знать, что справочник изменился?
2. это реально даёт выигрыш? с учётом сложностей с программированием и поддержкой?

моё имхо совпадает тут с Дмитрием, бесперспективняк. Кажется, что мы видим попытку оптимизации не в том месте, где тормозит.

1. Пользоваьтелю незачем это знать, я писал выше, обновляется по таймеру, т.е. в базе храниться время последнего обновления справочника(любого) и если необходимо, перечитываем нужный нам справочник, соотв. сложностей здесь особых нет.
2. выигрыш в том, что хеш хранится в одном месте, мне нет необходимости загружать данные по нескорльку раз. Ну вот для примера. Есть два объекта, которым нужны один и тот же справочник. По вашему каждый объект должен загрузить себе этот справочник, и тоже как то его проверять на изменения, верно? Я же, создал объект, всегда предоставляющий актуальные данные по справочникам, и оба объекта обращаются к одному актуальному справочнику. При чем я взял в пример хеш со строковым значением, но в место этого у меня применяются и объекты (контактные данные фирм и т.д.). Т.е. убиваем двух зайцев, сокращаем в разы трафик, а так же довольно удобный интерфейс, в случае большого приложения.

maytonWulffЭто как? Можете пояснить что такой "промах"?

Ну это похоже на работу DNS. Ты полез в свой локальный кеш. Не нашёл записи. Полез в DNS
следующего уровня. e.t.c. до самого верхнего. Но это полезно когда ты лезешь точно зная
новый ключик или знаешь что записи имеют time-to-leave.
Спасибо, догадывался что это именно так. Т.е. если вдруг в спарвочнике не нахожу нужную запись, то перегружаю справочник.

maytonДа но для ComboBox например такой вариант непрокатит
Ну это решается довольно просто с QAbstractItemModel, ооочень просто. Я сейчас все данные только через нее делаю, очень удобно и довольно гибко получается.

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

egorychWulffНу вот для примера. Есть два объекта, которым нужны один и тот же справочник. По вашему каждый объект должен загрузить себе этот справочник, и тоже как то его проверять на изменения, верно? что такое объект в данном случае? класс, представляющий бизнес-сущность? Если да, то не верно. Я считаю, что таких объектов вообще быть не должно.
Ну почему же? Допустим справочник адресов. Как можно в хеше хранить? Только в виде экземпляров класса, который содержит все поля. 1.Это удобно 2.Быстро, в плане доступа к информации

egorychКак часто срабатывает таймер, кстати?
Зависит от клиента, и от того что за справочник и вероятность обновления его. На практике это от 10 сек. Запрос делаю в отдельном потоке.