Система аккаунтов

[RaccoonAttack]

Доброго времени суток. Возникли следующие вопросы по системе аккаунтов:

Допустим, имеется бд в MySQL, там хранятся аккаунты игроков и вся информация о них. (в т.ч. транспорт и недвижимость игрока)

• Где лучше всего хранить все эти данные после логина игрока на сервер? (имеется в виду, чтобы не создавать каждый раз запрос к БД, а хранить где-то временную копию для данного аккаунта)
  
• Если эти данные хранить на стороне клиента, то как можно защитить эти данные?
  
• Есть ли смысл делать админ права через MySQL или же лучше пользоваться встроенным ACL?

Заранее большое спасибо.

[Disinterpreter]

• Где лучше всего хранить все эти данные после логина игрока на сервер? (имеется в виду, чтобы не создавать каждый раз запрос к БД, а хранить где-то временную копию для данного аккаунта)
  
• Если эти данные хранить на стороне клиента, то как можно защитить эти данные?
  
• Есть ли смысл делать админ права через MySQL или же лучше пользоваться встроенным ACL?

1. В таблице или в СУБД.

2. Какие эти? Данные от аккаунта лучше хранить в СУБД. (На сайтах же юзерданные не хранят на клиенте)

3. Тут вообще не принципиально, делай как тебе кажется удобнее.

[RaccoonAttack]

2. Какие эти? Данные от аккаунта лучше хранить в СУБД. (На сайтах же юзерданные не хранят на клиенте)

С динамическими данными-то все понятно. Если игрок захочет увидеть свой инвентарь - сделаем запрос в бд.

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

[Disinterpreter]

2. Какие эти? Данные от аккаунта лучше хранить в СУБД. (На сайтах же юзерданные не хранят на клиенте)

С динамическими данными-то все понятно. Если игрок захочет увидеть свой инвентарь - сделаем запрос в бд.

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

Ну игрок зашел, взял эти данные из СУБД и хранишь в таблице в Lua.

А вообще СУБД на то и созданы чтоб к ним обращаться, хранить и обрабатывать данные.

[RaccoonAttack]

Ну игрок зашел, взял эти данные из СУБД и хранишь в таблице в Lua.

А вообще СУБД на то и созданы чтоб к ним обращаться, хранить и обрабатывать данные.

Я не имел боевого опыта с MySQL и не знаю, как она отреагирует на нагрузки, поэтому и спрашиваю, стоит ли позаботиться о таком. Как я понял, особого смысла париться по поводу запросов нет?

[Fabervox]

On 28.08.2016 at 1:07 PM, Disinterpreter said:

2. Какие эти? Данные от аккаунта лучше хранить в СУБД. (На сайтах же юзерданные не хранят на клиенте)

От чужих аккаунтов нет, а так есть cookies, именно они работают в большинстве случаев для "быстрого входа" на сайт.

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

[Kernell]

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

Лучше будет при авторизации игрока загружать всю информацию на сервер и хранить её у себя, а при измении просто обновлять данные в БД. Много памяти это не потребует.

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

On 28.08.2016 at 0:59 PM, RaccoonAttack said:

Есть ли смысл делать админ права через MySQL или же лучше пользоваться встроенным ACL?

Лично я так и сделал, ALC используется только для системного администрирования, соответственно и учётки там только для сис.админов.
Связывать учётки MySQL и SQLite очень не удобно, да и лишняя информация начинает появлятся. По сути SQLite база становится системной.

On 28.08.2016 at 0:59 PM, RaccoonAttack said:

Если эти данные хранить на стороне клиента, то как можно защитить эти данные?

Никак

Edited September 17, 2016 by Kernell

[RaccoonAttack]

Спасибо за ответы. Я уже давно пришел к варианту кэширования и реализовал его.
 А где можно узнать, что вообще из себя представляет переменная client? (размеры хотя бы)