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

Текущие бои я бы советовал в memcache держать, а потом их в базу кидать. В принципе это тоже самое что и с таблицей memory в mysql. Только в случае сильных нагрузок - мускуль начинает тормозить и даже таблицы мемори не открываются. А так как memcache - это уже другой интерфейс то он будет работать стабильно, ну разве что вы всю память системы не выжрете ;)

"Вдруг" меняются правила, и в бою могут участвовать до 10 (или до 50) игроков.

В т.ч. состояние боя (т.е. каждого игрока) по итогам каждого хода.

"Раздувание" исключительно в размере кол-ва байт в ID-шниках. В остальном - если данные нужно хранить, они будут храниться и в одном поле, занимая тоже самое место. А вообще спорный вопрос, что больше места займёт.. ID-шники в чистом виде (при необходимости с поиском по ключу) vs они же, но сериализованные...

Не увидел EAV.. Обычная структура реляционной БД - сущности-ключи. Со всеми недостатками и достоинствами.

Хранение всего боя целиком в одной строке БД ИМХО быстрее приведёт к тормозам из-за блокировки строки (INNODB) UPDATE-ами. Хотя, вариант рабочий.. БД и в том, и в другом случае используется исключительно как хранилище.

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

Кстати, по теме будет интересно почитать как устроены некоторые моменты в уже готовых проектах:

http://habrahabr.ru/company/mailru/blog/182088/

http://highloadblog.ru/articles/7.html

[sys], спасибо за ссылки.

[sys], тарантул специфичен..

шаред не подойдёт (на VPS может встать, но... Часть анонсированных фич не будут задействованы. Интересно было бы про опыт использования почитать)

+ есть нюансы... http://sproger.ru/my-tarantool-try/

+ разрабатывается в mail.ru (в смысле, не классический "опенсорс")

В общем, имхо, для старта не айс.

offtop... После двух новогодних поздравлений спустя ~7 лет [sys] вернулся на форум

Спасибо, товарищи. Много полезного узнал. 450 онлайн - такие цифры не рассчитываются. Приложение по плану среднее, но буду писать один, уделяя по нескольку часов в день, неизвестно когда будет. Знаю php/c#, javascript, css, html.(почти все, кроме си шарпа прошел по курсам специалиста, си шарп и ооп в универе), из игр только мелкие писал на xna game studio, а вот базы данных только нынче осенью пойдут(а пока норм. базы данных для меня больная тема), я и пошел впереди воза, хотя сомневаюсь, что то, что в этой теме узнал, нам скажут.

Есть смысл почитать инфу по реляционным БД (понимание SQL, например.. для начала хватит первой главы)

ещё по SQL есть хороший /ИМХО/ ресурс для обучения http://sql-ex.ru

* Он хорош для понимания и для изучения возможностей. В реальности многоэтажные запросы вряд ли пригодятся. Зато после обучения проблем с JOIN-ами возникать не будет.

ivan-lev, тарантула я скинул для расширения кругозора, как это делается в больших проектах. А по теме я постом выше написал - надо юзать мемкэш(для онлайна) + мускуль(как архив) - этого по началу с головой хватит.

offtop... тут промашка, акк мой ) но у каждого свои причины для возвращения

Спроектировал таблицы заявок и боев. Реализовал серверную/голую клиентскую части.

Бои проводятся, простые - можно ходить, атаковать.

Захотелось разнообразия. Решил добавить расы, деревья навыков. Скрин(пример) из диабло 2.

Соответственно получаю таблицы:

1) Таблица соответствия юзера и расы: id_users id_rasa

2) Таблица рас: rasa id_rasa

3) Таблица соответствия рас и умений: id_rasa id_umenie(умение)

4) Таблица умений: id_umenie neobxodimiy_level action(действие, реализуемое умением)

5) Таблица юзеров и принадлежащих им умений: id_users id_umenie lvl_umenie(возможна прокачка каждого умения) - а вот эта таблица получается очень большой в плане строк. Чувствую, производительность здесь сильно упадет.

Специалисты, все ли правильно?