Проектирование бд, нужна помощь

???

Делается через таблицу many-many id_user id_battle (или какой там бой.. по англицки будет.), при необходимости доп поля (время входа юзера в бой, время выхода, итд)

в таблице боёв - инфа исключительно о бое.

как вариант - длинная "простыня" (на примере многоходового боя):

id_battle id_tick (тик/ход) type (пользователь, препятствие итд) id_obj (ид-

шник объекта типа type), доп инфо (статы-жизни, action=что сделал, направление=куда смотрит) итд

Так, спасибо. Пойду изучать.

Если я вас правильно понял:

Значит, у нас будет две таблицы: заявки - id_user id_zayavka. И заявки_параметр - id_zayavka, parametr(макс. кол. чел., время действия заявки). ?

Насчет боя:

Будет таблица боев: id_battle, id_tick(ход), id_user, action(что сделал, если ударил - ид_юзера, если сходил или оделся и т.д. - параметр какой-нибудь), value.

Делаем еще таблицу: id_battle, id_user, status(сходил/не сходил), xp.

Но если бой на время, которое и формирует ход. Каждый ход по минуте(за которую все должны успеть сходить один раз). Создаем еще таблицу боев, где id_battle, max_users, max_sxodilo, timer.

Как-то так?

это primary key

каждый юзер может сходить за конкретный ход в конкретном бою только 1 раз.

Инфу о том, что пользователь сходил - записываем в эту таблицу.

Если юзер 356 за 3-й ход в 155-м бою не сходил, то строчки с 155/3/356 не будет.

Если же сходил - в этой строчке должна лежать вся инфа о его ходе.

Таймер можно разместить в таблице боёв или вообще рассчитывать его (есть датавремя начала боя, есть 1 ход в минуту, есть текущее время).

p.s. зачем хранить max_shodilo (в смысле, что это даёт)?

Max_shodilo - если равно max_users, то значит все сходили и можно начинать новый ход, не дожидаясь окончания времени хода.

Для таких вещей лучше использовать nosql базы, вроде mongodb... в противном случае, бд начинает тормозить уже при нескольких десятков одновременных боёв.

Да не, если все норм сделать, должно держать. При нескольких десятках(30) одновременных боев(с 15 чел в каждом) около 45 000 записей будет в таблице боев-ходов при достижении всеми боями 100-го раунда, это немного. Да и вряд ли, такие масштабы будут, я так, практикуюсь, не более. Законченные бои , конечно, будут выгружаться в архив. Но я теоретик - новичок, утверждать особо не могу. Практикуюсь вот.

"45 000 записей" - это всего 30 боев... а если историю хранить, то получатся таблицы с многими миллионами записей. Но при грамотном программировании, потом не сложно будет перенести на другую систему хранения. Пишите пока на том, что знаете. Многие проекты так и умирают недожив до рабочего релиза... :)

Текущие бои в Memory хранить, архив - в MyISAM (меняться они вряд ли будут) или в InnoDB. Для начала - даже на шареде пойдёт.

Обнадёживающе :D

Это 450 активных игроков онлайн.. много это или мало (в смысле, завышенное или заниженное число) - Вам виднее.

Не вполне по канонам, но для Вашей ситуации - очень даже айс. Один бой - одна запись, размер записи ограничен исходно, все куда надо влезет.

Под бой вообще нет смысла разводить данные на ячейки. Сделайте базу данных из ИД, ТЕКСТ и в текст складываете сериализованные данные о бое.

Мы бы согласились с Вами в большинстве случаев, но не в этом. По сути у ТС в задаче нет ничего, для чего нужно SQL с одной стороны. С другой стороны при EAV решении будет нехилое раздувание таблицы, при этом высоконагруженной таблицы. А ведь nosql решение и/или пусть даже sql решение но без eav - позволило бы обойтись без этого.