Как мне правильно построить структуру данных для игры?

Question

[Кирилл Павлов]

Добрый день. Мне нужна базы данных и возник вопрос по структуре. Можно все поместить в одну таблицу(сообщения, достижения, перки, бонусы и многое другое), тогда столбцов у меня выходит порядка 25-27, либо разделить на таблицы по тем все это дело. Но тогда это усложнит обращение к данным да и регистрация игрока(создавать эти 3-5 таблиц), плюс проблема с джоинами какая то, не удобно в общем. Но по таблицам вроде как говорят будет производительнее. Как поступить, какой вариант выбрать?

Comments

[Akina]

Можно все поместить в одну таблицу(сообщения, достижения, перки, бонусы и многое другое)

Нельзя.

регистрация игрока(создавать эти 3-5 таблиц)

Это Вы о чём? Одна таблица на всех.

это усложнит обращение к данным

Ничего это не усложнит.

[Кирилл Павлов]

Akina,
нельзя почему?
усложнит тем что разве городить джоины
так одна все же или нельзя?

[FanatPHP]

как ты собрался сообщения в эту таблицу запихивать?

[Кирилл Павлов]

FanatPHP, json

[Кирилл Павлов]

там лимит по сообщениям и диалогам

[FanatPHP]

офигеть
а зачем тебе база данных вообще тогда? Над структурой еще голову ломать. Джойны какие-то. Пиши все данные в один джейсон файл.

[Кирилл Павлов]

FanatPHP, ты мне предлагаешь данные сотен игроков писать в джейсон??
join - https://ru.wikipedia.org/wiki/Join_(SQL)

[Кирилл Павлов]

по бд выходит что то такое
CREATE TABLE "Players" (
"GameId" INTEGER NOT NULL,
"GooglePlayId" TEXT NOT NULL,
"Nickname" TEXT NOT NULL,
"CrabCoins" INTEGER,
"Crystalls" INTEGER,
"Level" INTEGER DEFAULT 1,
"HP" INTEGER DEFAULT 0,
"PermanentItems" TEXT,
"SimpleItems" TEXT,
"Achievements" TEXT,
"Skills" TEXT,
"Pressets" TEXT,
"Friends" TEXT,
"FriendApplications" TEXT,
"Messages" TEXT,
"Notifications" TEXT,
"Status" TEXT COLLATE RTRIM,
"LastOnline" TEXT,
"LastGotBonus" TEXT,
"StartedGetEveryDayBonus" TEXT DEFAULT 0,
"LastChangedNickname" TEXT,
"BonusGettedDays" TEXT,
"PlayerStatistic" TEXT,
"UnreadedMessages" TEXT,
PRIMARY KEY("GameId")
)

[Кирилл Павлов]

столько полей выходит

[Василий Банников]

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

[Василий Банников]

Кирилл Павлов,

ты мне предлагаешь данные сотен игроков писать в джейсон??

Ну ты же не видишь ничего странного в том, чтобы данные о разных сущностях в одну таблицу пихать, при помощи json - почему бы тогда не пойти на шаг дальше?

[Кирилл Павлов]

Василий Банников, при помощи json используется всего лишь несколько полей. те же перки и ачивки, или нужно создавать еще десятки полей для всего этого?

[Василий Банников]

Кирилл Павлов,

или нужно создавать еще десятки полей для всего этого?

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

[Кирилл Павлов]

Василий Банников, может и напишу, но для небольшого моего проекта это вроде как подходит, недостатков особо не вижу

[FanatPHP]

ну если не видишь, то зачем сюда-то пришел?
ты же у нас гений, который лучше всех всё знает

[Кирилл Павлов]

FanatPHP, я пришел получить точный совет. сарказм не уместен.

[FanatPHP]

точный ответ тебе дали в первом комментарии

[FanatPHP]

но деточка ужасно боится страшных джойнов и поэтому канючит "ну дяденьки, а можно джейсон?"

[Василий Банников]

Кирилл Павлов, ну давай помогу найти проблемы)
1. Нужно ли делать запросы по полям, которые хранятся в json-объектах?
2. Будет ли происходить обращение к данным из разных потоков? (к вопросу о выборе СУБД)
3. Как посчитать количество предметов в инвентаре игрока, не вытаскивая информацию о всём его инвентаре?
4. Что делать, если например какой-то предмет стал запрещённым, и его надо убрать у всех игроков из инвентаря?
5. Как получить список игроков, которые были онлайн на последней неделе?
6. Что будет, если игрок напишет несколько сотен максимально больших сообщений?
7. Что делать, если вдруг захочешь удалить все сообщения всех игроков, которые содержат какое-нибудь стоп-слово?
8. Что делать, если вдруг название какого-нибудь скилла изменится?

[Akina]

Кирилл Павлов,

по бд выходит что то такое

И вот теперь представь. Трындят два игрока, перекидываются сообщениями по одному смайлу. И ты в каждую запись к этому смайлу будешь приписывать всю вот эту кучу информации - никнейм, друзья, достижения... серьёзно? да у тебя диск через час закончится.

Базы данных не ляпаются на основании информации с потолка. Сначала надо проделать серьёзный анализ предметной области.

В общем, почитай хоть что-нибудь по теме "Нормальные формы". Для начала.

[Кирилл Павлов]

1) нужно будет, так же будут перезаписываться
2) будет один поток отдельный от основного отвечающий за базу данных, кратко говоря, с базой будет работать один поток
3) тут по столбцу только
4) такой возможности увы нет
5) тут боюсь придется все вынимать из базы данных..
6) можно пройтись по бд и вытащить по последнему онлайну
7) сообщения сами по себе будут иметь ограниченную длину, и количество их в диалоге будут ограничиваться порядка 50-100.
вот и хочу сделать все оптимально, так что, благодарю за помощь.
8) пока не продумал

[FanatPHP]

чтобы было понятно такое отношение
нормальная структура данных - это как таблица умножения
ты тут сейчас ходишь и спрашиваешь, "ну можно дважды два будет не 4, а 5?"
если будешь дальше учиться, то через годик посмотришь на этот свой вопрос и тоже ужаснёшься

Да, надо учить SQL. Но ты уж определись - или ты учишься делать нормально, или говнякаешь как в голову взбредёт, но тогда не надо никого спрашивать.

[Кирилл Павлов]

FanatPHP, наверное

[Василий Банников]

Кирилл Павлов,
1. Будет явная проблема с производительностью, тк придётся вычитывать всё в память и фильтровать на стороне приложения, тк sqlite не умеет в json
2. Значит каждый пользователь будет испытывать дикие лаги каждый раз, когда его действие задевает бд
3. Это не ответ. Правильный ответ - никак
4. Есть. Выгрузить всю базу и поредачить каждую запись на стороне приложения, а потом загрузить обратно.
5. ага
6. Этот вопросы был про сообщения. А ответ такой: приложение будет потреблять огромное количество ОЗУ каждый раз, когда дело будет касаться сообщений.
7. Ну допустим каждое сообщение будет по 100 символов. 100 * 100 уже 10к.
8. А всё то же самое - вычитывать всю базу и заменять текст.

[Кирилл Павлов]

1. Проблемы не особо, повторюсь, запросы sql в отдельном потоке, а для json используется встроенный модуль unreal, который проверял, жрет не очень много. Основной поток сервера будет чувствовать себя хорошо.
С сообщениями пожалуй беда, но как тогда поступить? По памяти в базе.. ну думаю это будет несколько десятков килобайт на юзера.

[Василий Банников]

Кирилл Павлов,

Проблемы не особо, повторюсь, запросы sql в отдельном потоке, а для json используется встроенный модуль unreal, который проверял, жрет не очень мног

Но заметно больше, чем без него.

С сообщениями пожалуй беда, но как тогда поступить? По памяти в базе.. ну думаю это будет несколько десятков килобайт на юзера.

Это только с учётом текста, а что у вас там в жсоне будет - это уже отдельная проблема.
Есть много способов, как можно вроде короткое сообщение сделать так, чтобы оно много байтов занимало.

[Роми]

FanatPHP, лучше в xml

Answer 1

[acwartz]

У вас проблема не с SQLite а целиком со знаниями баз данных и SQL в частности.

Можно все поместить в одну таблицу(сообщения, достижения, перки, бонусы и многое другое), тогда столбцов у меня выходит порядка 25-27

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

Пользователи это таблица Users где есть поле ID котрое получает значение при вставке записи и это значение не меняется.
Есть сообщения это таблица Messages.
где есть Autokey получающее значение при вставке записи, есть поле-индекс DateCreate с датой и временем создания сообщения, есть поле Message - текст сообщения, так же поля От кого (ссылка на Users.ID) и кому (Users.ID)

Есть ачивки, таблица Achivements:
Поле UserID (Users.ID) связь с тем кто ачивку получил
Поле даты и времени получения,
поле идентификатора ачивки
поле описания ачивки
поле с картинкой ачивки

Бонусы, таблица Bunuses:
Поле UserID (Users.ID) связь с тем кто бонус получил
Поле даты и времени получения,
поле идентификатора бонуса
поле описания бонуса
поле с картинкой бонуса
поле обозначающее позитивный или негативный бонус
поле даты и времени завершения действия бонуса, если NULL то бонус вечный

Таблица с перками - Perks:
Поле UserID (Users.ID) связь с тем кто бонус получил
Поле даты и времени получения,
поле идентификатора перка (PerkID)

это все легко расширяется новыми полями и если надо обрастает новыми связями с новыми изменениями.
А если вы все в кучу кидаете, на кой вам вообще база данных?
загоняйте все в json/xml.

Comments

[Кирилл Павлов]

ладно, в общем спасибо, учту.

Answer 2

[Роми]

Можешь почитать например это: https://habr.com/ru/post/193756/

В любом случае, если ты хочешь стать программистом, тебе ПРИДЕТСЯ понять, что такое "нормализованная база данных", либо забить на программирование.

Ну, просто потому, что это такие же основы, как, циклы, массивы, условные операторы, и т.п.

Не хочешь учить SQL? Не вопрос: возьми какой-нибудь Laravel и используй ORM Eloquent - может это тебе попроще будет.

Но в любом случае основы хранения данных в базе лучше-таки понять.

А то будешь как мой нынешний тимлид говорить потом подчиненным: - Вы зачем столько лишних таблиц создаете? Они тормозят базу!

//а там по факту таблицы были для отношений многие-ко-многим )))

Comments

[Кирилл Павлов]

Стать? Мне нужно закончить мобильный проект на unreal engine, и осталось лишь разобраться с базой данных, вот и задался вопросом. Просто порядка полутора года не затрагивал особо тему с хранением данных кроме как мелких ботов.
ORM я бы так же затронул, а то о нем вообще как то мысли не было..
А поводу таблиц да, ирония, как раз возникла некая дилемма с членом моей команды, что я совсем не правильно напихал все в одну таблицу, вот и начал узнавать, пришел к такому вопросу).
Статью обязательно прочитаю, благодарю.