Arhat109У-у-у как всё запущено... :)
Монстры, артефакты, ачивки и прочие сущности, по-хорошему надо моделировать собственными таблицами-справочниками, пардон в терминах РМД "отношениями". И делать отдельно связи с игроком, (пардон опять же "отношения" - таблицы) в части "какой_игрок - какая-сущность - сколько_создал - когда_создал - как создал - сколько_убил - когда_убил - как_убил"... ну или допустить что сколько > 0 -- стало быть создал, а ежели меньше, то убил... а не лепить всё в одну таблицу связи, пардон "отношение"... :)
Может я что то не правильно понял, но на данный момент схема такая:
1) Есть набор сущностей, каждая сущность ограниченное множество. Например, юниты, их 16 штук, они все в отдельной таблице с 16 записями. У каждого юнита есть свой ИД и только присущий ему набор свойств (здоровье, атака, защита и так далее).
2) Есть таблица юзеров, в которой свойства присущие только юзерам и разумеется ИД.
3) Есть таблица связей каждой сущности и каждого юзера, например "уничтоженные юниты". Вот именно о схеме таких таблиц я и задал изначальный вопрос, возможно несколько размыто и не точно, сорри.

Или же вы предлагаете сделать вообще одну таблицу на связь всех сущностей?
То есть ид_юнита, тип_сущности, ид_сущности, количество?
Где тип сущности может быть совершенно любой? То есть от созданных юнитов, до открытых ачивок (всего их 12 штук)?

MasterZivЭто всё не проблема. Запросы будут быстрыми как на чтение, так и на изменение, при условии, что везде будет фильтр по одному игроку. А он тут есть.

Я думаю, ты ошибаешься.
Поясни, какие UPDATE-ы будут происходить в несколько раз медленнее ?

Вы совершенно правы, скорость обновления для одной записи (where id_user = N) примерно одинакова при первом и втором варианте построения таблиц. Но проблема в том, что за один раз (за один вызов скрипта) нужно апдейтить разное количество записей, от 0 до полного обновления всего. Следовательно в первом варианте мне нужно сделать множество запросов на апдейт, что суммарно даст большее время, чем один апдейт на одну сущность при втором варианте. Собственно я это уже проверил экспериментально, разница до 10 раз по суммарному времени апдейта.

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

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

Arhat109проверил
Спасибо! Все примерно так же.
И все же получается второй вариант в целом более производительный, чем первый и имеет некое право на существование?

Arhat109ewb, конечно имеет. Впрочем как и третий... :)

У вас больше проблема с пониманием проектирования БД в целом, чем со способом хранения (1,2 или 3). Это сложнее чем Вы себе сейчас понимаете... я бы посоветовал, отойти слегка от задачи и почитать литературу какую-нибудь (тут рядом топик есть).

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

Это так, рекомендации от человека проектировавшего игрухи военного жанра... :)
Благодарю за помощь! Так и сделаю.
В соседний топик уже заглянул:)