Симонов Дениспогоди. Иметь таблицу в памяти с кучей записей это одно. Совсем другое иметь возможность получения констант без обращения к таблицам."ТАБЛИЦЕЙ" я назвал эту структуру просто по инерции. Это должно быть то, что в java называется TreeMap'ом - структурой, реализующей междуморд Map, и представляющей из себя красно-черное дерево. Не знаю, как в std c++ это зовётся, вроде бы тоже Map. Главное - это скорость доступа, она должна быть O(log N).

Симонов Денис In-memory таблица вещь хорошая, но в тройке и так дофига чего ещё делать. Может в каком нибудь 3.1 и будет. Оформи хотелку в трекер.Бесполезняк. Ибо там меня всегда ждёт Шон
Лучше здесь зондировать по-максимуму, пока Светила не скажут вердикт.

Симонов ДенисКстати тут тоже кроется недостаток. Как за памятью такой таблицы следить?То есть ?

dimitrСимонов Денисне мне кажется он совсем без блокировок хочет
грязную запись? ню-ню...Да. Да! Именно так: ГРЯЗНУЮ запись. Чтение из этой структуры МОЖЕТ быть привести к несогласованным результатам. Пусть перечитывают, если "не нравится" - не развалятся.
Для чистых записей есть fixed-таблицы.

dimitrценой блокировки уровня таблицы, а-ля MyISAM? Я уже говорил данунах? :-)оставим даунам дауново... мне бы в страшном бреду не привиделось предлагать лочить всю таблу.
Кстати... а где ты говорил про даунов ? что-то я пропустил, кажется...

ТаблоидЧтение из этой структуры МОЖЕТ быть привести к несогласованным результатам. upated.

miwaonlineТаблоидКстати... а где ты говорил про даунов ? что-то я пропустил, кажется...
"Данунах" - это не о даунах ;)А, да... глаза замылены... но что-то всё-таки навеяло, не знаю даже что именно...

dimitrТаблоидДа! Именно так: ГРЯЗНУЮ запись. Чтение из этой структуры МОЖЕТ привести к несогласованным результатамаффтар, пеши исчо!Чё там не так ? :-)
я спросил именно про структуру, которая должна
* хранить данные, видимые всем коннектам,
* не быть персистентной (т.е. храниться в ней должны только данные, потеря или нарушение согласованности которых не имеет значения для бизнеса) и
* иметь максимальное быстрод-вие, пусть и за счет возможной несогласованности при считывании.

Ну, так что тут "пешать исчо" ? :-)

Ivan_PisarevskyМабыть Таблоид нечто вроде GTT, которое не материализуется на диск, но видно всем коннектам?

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

Гаджимурадов Рустамdimitr> ему не нужны переменные, ему нужны таблицы без таблиц

Это другая хотелка. :) А что насчёт неймспейса GLOBAL ?Это та же самая хотелка. Твой "namespace global" - просто строгое научное определение этому :-)

Гаджимурадов РустамЗавтра ты (или кто другой), скорее всего,
захочешь больше - и индексы, и констрейнты (что вполне логично).Кто захочет большего - велкам в мир fixed-таблиц.
Индексы, кстати, я не просил: map-структура, реализованная в виде treemap'a, и есть индекс. Данные достаются сразу из него, никуда дальше лезть не надо.

Гаджимурадов РустамТаблоид> * иметь максимальное быстрод-вие, пусть и за счет возможной несогласованности при считывании.

Несогласованное чтение там, в общем-то, необязательно, AFAIU.Тогда синхронизацию доступа надо ваять. Лишние затраты, да и опять всё станет похоже на мир fixed-таблиц.

dimitrТаблоидТогда синхронизацию доступа надо ваять
ты лучше проспись и с утра подумай, что будет с твоим красно-черным деревом (или любой другой связанной структурой) при параллельном изменении без синхронизации доступапфф... да, сглупил... каюсь :-[
Ладно, пусть дальше Источники Света решают, витать дальше этой идее в воздухе или в топку её.