1 игрок - 1 файл. Мысли

[Ayk]

Вечер в хату. Добрый вечер.
Хочу узнать ваше мнение о таком способе хранения данных, применимый к серверу CS 1.6, как: 1 игрок (аккаунт) - 1 файл.
Другими словами, вся информация об одном игроке хранится в файле названый как STEAM ID игрока.
С учетом введения JSON API это будет json файл.

У кого какие мысли?
Какие для вас видятся плюсы и минусы?
Предложения?
Предостережения?
Альтернативы?

Давайте обсудим.

 

[CrazyHackGUT]

Какие для вас видятся плюсы и минусы?

- Отсутствие нормального поиска по такому файлу.
+ Возможность редактировать данные без постороннего софта.

Предостережения?

В иноды можешь упереться. Особенно когда игроков очень много. Сомневаюсь, что такое вообще может произойти в 1.6 мире, но кто знает ?

Альтернативы?

SQL база (тот же SQLite), и не надо ничего придумывать.

 

[zhorzh78]

С учетом введения JSON API это будет json файл

Тогда, без разницы, где хранить. В файле (разумеется, не отдельном для каждого игрока), в БД, vault и т.п.. Парсер json в плагине будет обрабатывать строку одного и того же формата. Это проще, чем парсить строки из файла или столбцы из бд- для каждого случая потребуется свой код.

 

[Ayk]

Еще можно отметить следующее:
минусы:
- никакого ТОП Х игроков не сделать (не открывать же все файлы в конце концов).
плюсы:
- успешное открытие файла сразу сообщает о том что: а) такой аккаут существует и б) информация доступна к чтению по ключам.

А так, да, SQL всему голова.

Я недавно увидел простецкий плагин рангов, и там информация сохраняется через fvault.inc.
Каждая загрузка или сохранение данных подразумевает чтение всех строк файла в поисках нужной строки. Ужас.

 

[CrazyHackGUT]

Каждая загрузка или сохранение данных подразумевает чтение всех строк файла в поисках нужной строки. Ужас.

Если не расставить ключи на нужных колонках в SQL базе - получишь то же самое: СУБД, в попытках найти твою строку, будет читать все строки полностью, пока не дойдёт до нужной.

 

[SISA]

Для хранения данных был разработан MySQL. Зачем изобретать велосипед и перекладывать работу с данными на игровой сервер ? Если идут частые обращения к базе или нужен мгновенный доступ к данным, закешируйте их в многомерный trie массив и синхронизируйте его с БД по мере необходимости.

 

[CrazyHackGUT]

Для хранения данных был разработан MySQL.

Почему только его упоминаете? Данные можно и в SQLite хранить, и в PostgreSQL. Необязательно даже привязываться к реляционным СУБД.