ВКонтакте API

Каждому экземпляру приложения доступно до 4096 переменных (0-4095), в каждой из которых можно хранить строку из не более чем 255 байтов.

"Каждому экземпляру", - это значит, что вконтакте может храниться 4096 переменных с данными от каждого пользователя установившего приложение, я правильно понимаю?
Или все-таки 4095 на всех пользователей приложения?

Глобальные переменные (0–1023) для всех пользователей одинаковые.
Пользовательские переменные (1024–2047) для каждого пользователя свои.
+ ещё сессионные есть

Это всего 1000 на пользователя выходит... маловато будет Так и придется лишнюю инфу в бд держать.
Спасибо за ответ

скромное имхо: лучше все держать у себя на сервере

bodnar, да я хотел хранить в них количество действий совершенных у каждого друга, чтоб не делать лишних запросов к себе на сервер. Да и количество данных все-таки получается нехилое, если у каждого пользователя по 1000+ друзей будет.
Вот теперь думаю как лучше сделать:
Держать тысячи мелких записей в базе типа ID_пользователя | количество_действий.
Или для каждого пользователя держать список в одной строке, а потом скриптом ее разбивать на подстроки.
Склоняюсь все-таки ко второму варианту.

список чего?
как кол-во (которое по сути число) соотносится со списком( который по сути набор каких то значений) из второго варианта?

Список друзей с количеством действий у них.Например в JSON и забивать в БД.
По-моему такой вариант экономичнее, чем забивать каждого друга и количество действий у него в свою строку таблицы БД. Только косяк в том, что когда нужны сведения об одном друге придется каждый раз из базы весь список тягать.
Вот и думаю, либо нагрузка на базу, либо на скрипт.

одна таблица в бд

1. uid пользователя
2. id друга
3. кол-во действий

составной первичный ключ два первых поля
вполне удобно манипулировать

bodnar, мы просто не совсем понимаем друг друга. Чай я тоже не вчера на свет родился понимаю, что это одна таблица Но вот строк в этой таблице... Если предположить скажем, 50.000 игроков, и взять в среднем у каждого 300 друзей. То получается 15 миллионов строк, а если игроков миллион то вообще страшно представить. Я просто пока еще не сталкивался с таким большим объемом данных, вот меня и гложет вопрос, а выдержит ли MySQL? Может лучше как моем посте выше поступить? Или есть средства более рациональные. Хотелось бы узнать, как другие разработчики решают вопрос с большими объемами данных. Или скажем как вариант, если такие данные в файлах хранить а не в базе?

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