rodb... и извлекать объекты по ObjId и TypeId....

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

Объектная модель подразумевает оперирование объектами, а не безликими цифрами...А Если так - то у Вас только одна плоскость хранения - ObjectId данного определённого типа объекта. Но если приглядеться более внимательно - то и искать по ID объекта, не всегда реальная задача... Точнее эта задача появляется при условии анализа взаимодействия между объектами и только. В других случаях - Вы по определению ЗНАЕТЕ и ObjectID так же...


с уважением
(круглый)

rodb...Это объектики представляющие собой хранимые объекты в базе.
Поэтому мне и надо с ними взаимодействовать через Кэш клиента....

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

имеем тип...
по типу определяем класс объектов...
обращаемся к коллекции ДАННОГО типа объектов с просьбой - верника мне объект с этим ID...
коллекция шукает в памяти - нет...делает запрос к базе, подымает, делает референс на объект, увеличивает ссылку...возвращает референс...для пользователя - это объект (сам референс маскируем и выдаём за чистого арийца, тьху объект).
получили объект, далее работаем с ним по коду...
------
ссылки сдохли - объект (в зависимости от политики) мона грохнуть..

с уважением
(круглый)
ЗЫ
Возможно я опять Вас не понял :)

rodb..каждый стринг в листе содержит стринг вида TypeId + "." + "ObjId"...

сравните то, что написал я выше и Вашу реализацию (пока опустите способ хранения)... различие заключается в том, что Вы ищите во ВСЁМ множестве, а то что озвучил я - только во множестве ДАННОГО типа - а это заведомо МЕНЬШЕ. это раз...

два...способ хранения для идентификации... если уж использовать кэш - то нужно попытаться уменьшить размерность поля сравнения при поиске и попытаться задействовать стандартные, соптимизированные алгоритмы... выше предпалагалось, что в том типизированном объекте (что нашли Вы по идентификатору его класса) содержится коллекция сгенерённых ОБЪЕКТОВ от ДАННОГО класса. Если так - то достаточно сделать поиск в данном массиве данных - как из вариантов, std::map. Единица сравнение ID (как int). Компактность хранения и скорость сравнения (за одну (грубо говоря) машинную команду). Если же взять строку, то они сравниваються по байтно. Скорость сравнения зависит от кол-ва байт. В Вашем случае будет нечто (если Win32 и размерность int) 10 байт + 10 байт = 20 байтные строки. Если они в добавок валяються не упорядоченно в памяти - то анализ идёт методом тупого перебора. Что является ышо более не оптимальней (в данном подходе более оптимальнее их хранить упорядоченно по возрастанию или убыванию - тогда сравнение займёт столько "подходов к снаряду", сколько содержиться степеней двойки в данном кол-ве строк).


с уважением
(круглый)

rodbТеперь нам осталось выяснить, что будет оптимальнее

map< pair<int, int>, TObject*>илиmap< pair<int>, map< pair<int>,
TObject*>>ну я имел ввиду мап в каждом элементе которого находится мап
указывающий на TObject.возможно даже вектора подойдут?С Уважением.

Вы не внимательно читаете...зачем Вам пара идентификаторов, когда мона обойтись одним ? Чтоб было ? Если Вы и так уже знаете ТИП объекта ? :) Не, предлагаю туда же запихнуть цвет, высоту, ширину ваших объектов... про запас так сказать...

или по другому...
у вас есть столы, стулья, шкафы... Вы берёте некий идентификатор ТИПА (класса объекта) и определяете - ага, это стул... А потом говорите - не, не буду только (экземпляры этого класса - ОБЪЕКТЫ) стулья смотреть, буду ВСЁ просматривать - вдруг среди столов найду МОЙ стул...наверное круто, но ЗАЧЕМ ?

с уважением
(круглый)

rodbДак я заведомо еще не знаю сколько в программе будет типов и их
идентификаторы.

вот...теперь всё стало на свои места...
простите, но ЛЮБОЙ объект несёт "свою" типизацию. Если у Вас типизации нет - то увы и ах говорить об объектном подходе - мягко говоря не в ту степь... Давайте про типы поговорим !? Эээээээ у Вас чем отличается объект А от объекта Б ? Идентификационным номером ? кхм..а какого лешего идёт попытка использовать терминологию ОО тогда ? у Вас батенька ОДИН тип и зовётся он int... тогда данное решение - Вы уже приводили, двухмерный масив и вперёд... Поиск в данном случае должен занимать на 10000 экземплярах одного типа "всего" 16 сравнений...

Пример...
Берём кошку, собаку, стол, стул...пропускаем по очереди через мясорубку... И по кол-ву опилок бум говорить 34102 - это кошка... 3541 - это стул... 6788 - это стол... ну собака была маленькая и её кучка 356 без имянных частиц... :) Вот так приблизительно выглядит Ваш подход в программировании, если его спроецировать (реинжинеринг) на ОО методологию....

если строго следовать Вашему вопросу (в русле ООП) - то решение уже было озвучено мною выше.

рекомендую почитать Гради Буча...всё таки классика...
Как подсказку, могу вякнуть следующее... Нахфига вообще ООА ? Что он даёт ? Разбиение (группировку) на некие логические классы ? Увы и ах - это ОЧЕНЬ маленькая толика того, что даёт сей подход. Люди которые не вникли в суть происходящего - обычно рассуждают именно об этом... ОО подход гораздо бОльшее в себе содержит...Например уменьшение переделок кода со временем. Это не на поверхности - но это так... В задачи данной методологии входят такие вещи как нахождение тех сущностей, которые будут СЛАБО изменяться с течением времени. За счёт чего ? спросите Вы... А вспомните как строиться данная методология ? Правильно, от ЗАДАЧИ ! Вот это фундаментальный кирпичик ! Что это значит ? Это значит, что если пользователь (заметьте НЕ программист, НЕ аналитик - а ПОЛЬЗОВАТЕЛЬ!!!) рассуждает в своей постановки об машинах и колёсах - значит это претенденты на сущности под описание....и т.д.. пересказывать не буду... лучше почитайте повнимательней...к сожалению - это одна из самых распространённых ошибок в данной плоскости вопроса...


удачи Вам
(круглый)

rodb.....чтобы не пороть чуш в конференции.....

очень аргументировано... :)
пожелаю удачи лично Вам и особенно Вашим пользователям...

с уважением
(круглый)
ЗЫ
Эх молодёжь...молодёжь... эту бы энергию, да в мирное русло !!!

rodb.....чтобы не пороть чуш в конференции.....

очень аргументировано... :)
пожелаю удачи лично Вам и особенно Вашим пользователям...

с уважением
(круглый)
ЗЫ
Эх молодёжь...молодёжь... эту бы энергию, да в мирное русло !!!

rodbА вы на каком курсе учитесь?

на курсе молодого дедушки :)

с уважением
(круглый)
ЗЫ
Помню как лет тридцать назад прикалывали диодики к манжетам одежды. Нечто оригинальное получалось. С тех пор и сохранилась привычка - в спешке привинчивать оторвавшиеся пуговицы подручными резисторами и диодами :) Правда после критики первой жены - постарался перевоспитаться....гы..

rodb...По крайней мере чувство юмора у вас осталось....

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


удачи Вам
(круглый)

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

простите, я про язык С++ вообще то :) . если в С++ не применять типизацию - то нахрена вообще Вы пользуете данный инструментарий ? Ради стрнкопи ? Замечательно подойдёт фортран, си, ассемблер тогда..Если Вы говорите не про абстрактные типы, а "чиссо" из предметной области. и эти типы динамические (по условию задачи) - то нужно закладывать ту типизацию, с которыми оперирует заказчик...

Пример...
Заказчик хочет оперировать зайцами... Но на момент их генерации их типы будут меняться одно-двух-трёх-четырёх-пяти ногих... серых-белых. с квадратной головой и круглой и т.д.. Многое или почти всё, что я тут обозвал - проситься на свойства, но может быть и сущностью...
Пример..
Треуголную голову мы можем отделить от зайца и впендюрить волку. Круглая имеет пимпочку, которая открывается и в необходимый внутренний слот вставляется новый кусочек памяти... Приведённые сущности уже не свойства, а самостоятельные объекты, с которыми (заметьте) ОПЕРИРУЕТ ЗАКАЗЧИК !!!

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

с уважением
(круглый)