@deforder

Здравствуйте!

Разрабатываю сайт-движок для игры в текстовые квесты специфического внутреннего формата. На стороне сервера использую PHP и MySQL.

Когда пользователь выбирает "квест" и начитает новую игру, для этой игровой сессии генерируется "окружение". Размер окружения достаточно большой - порядка 5000-10000 элементов. Каждый элемент имеет набор параметров/свойств/состояний. Разных параметров есть несколько десятков, хотя для каждого отдельного элемента актуальны лишь 5-10 из них. "Вес" одного элемента (сумма "размеров" полей) ожидается на уровне 100-500 байт.
Структура окружения иерархическая. Условный центральный узел распадается на несколько крупных ветвей ("локаций"), внутри которых идет дальнейшее дробление.
Все параметры могут меняться, то есть "постоянные" параметры отсюда уже выделены в отдельную "таблицу шаблонов/классов".

На каждом этапе пользователю отправляется информация об одной из "локаций" (500-1000 элементов со всеми свойствами и структурой). Пользователь выбирает некоторое действие и посылает его на сервер. Сервер обрабатывает действие, обновляет состояние некоторых элементов (как правило, 10-15 штук, возможно изменение иерархии). После этого пользователь снова получает новую порцию информации.

Сама игровая сессия не лимитирована во времени и может продолжаться на протяжении многих дней (а то и месяцев). Если пользователь начинает новую партию, старое "окружение" удаляется.

Хранить текущее "окружение" планирую в базе данных. Соответственно, у меня возникает вопрос о структуре базы. Пока вижу два принципиальных варианта:
1. Для каждого пользователя создавать отдельную таблицу, в которой хранить элементы текущей игровой сессии.
2. Держать одну большую таблицу для всех пользователей, прикладывая к элементам id пользователя или игровой сессии.

Вариант хранить всю структуру в одном поле (XML?) откинул из-за больших затрат на парсинг. Разве что для сохранений можно подумать...

Поискал в сети подобные проблемы - почти везде советуют реализовывать второй вариант. Но тут вроде как специфика толкает к первому. Во-первых, сразу много записей на каждую игровую сессию. Во-вторых, игровая сессия отдельного игрока вообще никак не связана с остальными. В третьех, обработка окружения на каждом этапе идет достаточно интенсивная, делается выборка из порядка 10% элементов.

Прошу помочь советом. К какому варианту лучше склоняться?
И вообще, насколько жизненоспособен план в описываемой части с учетом данных оценок?
Может, подскажите какие подводные камни, которых я пока не вижу.

Спасибо!

0

@qwertehok

Таблицы не стоит динамически создавать
Лучше завести пользователя, и писать в общую

Зы вообще же 10к элементов это очень много

0

@deforder

А если все же разделить структуру на 10-20 "локаций" и записывать каждую из них в одно большое текстовое поле на 500-1000 элементов. Стоит ли регулярный парсинг такой части экономии на строках таблицы?

0