В чём это хранить?

bdb, значение сериализовать, например в json.

Если сервер один, конечно.

Осмелюсь предложить JSON и что-нибудь вроде MongoDB?

А монга не?

Сервер один, да. Т.е. их много, но они между собой не связаны.

Mongodb. Можно и couchdb, но у него надо писать заранее созданные map/reduce запросы, и «динамичность» немного пропадает.

Если всё же нужны индексы по свойствам, то тогда монго.

Желательны. Будем пробовать :}

// Всем спасибо, хотя если есть что добавить… :3

memcache

QList<QMap<Q...>>>

Это уже внутри, а мне бы снаружи.

OpenLDAP ==> bdb и сериализация уже в комплекте.

Ненависти ради: PGSQL::hstore

Если не надо править руками снаружи, а просто хранить - можно использовать встроенную в Qt сериализацию (QDataStream)

redis и msgpack

MongoDB

че то я не понял, чем вам SQL не угодил? может вы концепцию использования недопонимаете? очень логичный и понятный язык. создайте табличку с тремя полями (player_id, property_id, property_value), ну если надо можно табличку свойств еще (prop_id, prop_name) например. и вот сопсно все.

> Свойства произвольны и могут быть разными у разных пользователей и заранее они неизвестны (скриптами создаются при необходимости).

не катит, думай дальше.

>Ненависти ради: PGSQL::hstore

Что, он так плох? А я хотел как раз его попробовать в следующем проекте...

Ненависти ради: PGSQL::hstore

плюс сюда

оздайте табличку с тремя полями (player_id, property_id, property_value), ну если надо можно табличку свойств еще (prop_id, prop_name) например. и вот сопсно все

ага, и всё.. всё это будет дико тормозить, если не использовать для того же SQL специальные средства типа hstore.

>создайте табличку с тремя полями (player_id, property_id, property_value), ну если надо можно табличку свойств еще (prop_id, prop_name) например. и вот сопсно все.

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

Тогда уж делать prop_value_int, prop_value_timestamp, prop_value_str. Ну а идеально - так вообще взять постгрес и пользоваться его индексами по функциями.

Но всё это - красноглазие и костыли, когда можно просто взять монго или что-то ещё. Мы не в 2001 году же.

Он божественен, в том вся и соль. Просто у ТС ненависть к сиквелу.

Посмотри еще на Solr: есть поддержка динамических полей, можно строить по ним фасетные фильтры, быстр, но требует памяти так как java. Но я бы не рискнул хранить данные в Солре без дублирования где-нибудь еще.

>ага, и всё.. всё это будет дико тормозить, если не использовать для того же SQL специальные средства типа hstore.

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

>Тогда уж делать prop_value_int, prop_value_timestamp, prop_value_str. Ну а идеально - так вообще взять постгрес и пользоваться его индексами по функциями.

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

>да ладно, чему тут тормозить, элементарная выборка по одному primary ключу

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

EAV - костыль, придуманный потому, что кроме SQL БД не было ничего production-ready на тот момент. Да и сейчас есть нюансы с этими монгами и прочими модными штуками. Плюс ACID.

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

Если же у вас чётко определённая схема данных - тут sql вне конкуренции.

Вот кто-то набросал условный тест: http://fiery-fenix.kiev.ua/archives/33-EAV_vs_Row_Modeling._Test_proizvoditel...

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

xml/json ?

Мне, конечно, нравится XML но это не тот случай :)

xml чем не угодил?

А выборку из него ты предлагаешь каждый раз делать, когда пользователь заходит или держать вообще всё в памяти, даже тех, кого лет 100 не было? :)

А выборку из него ты предлагаешь каждый раз делать, когда пользователь заходит или держать вообще всё в памяти, даже тех, кого лет 100 не было? :)

Держать в памяти только активных, остальных в архив. Вроде логично?

Как-то всё это звучит затратно по времени.

Как-то всё это звучит затратно по времени.

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

Иногда приходится оббегать весь список, не хотелось бы. Ну да посмотрим ещё, что подойдёт.