Сохранение статистики боя против каждого соперника

[Ayk]

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

Проблема: сохранить статистику боя против каждого соперника (сколько раз я убил его, он меня, урон мне/ему, и т.д.).

Всё к чему я пришел в данный момент, это необходимость сохранять массив с уникальными идентификаторами игроков с которыми сталкивался в бою.
Как это сделать и что/где искать по этому ИД не представляю...

Заранее всех благодарю.

ЛЕ: я вот думаю об инвентаре в КСГО. Там массив с ИДшниками предметов (верно же?), и по этим ИД дёргается инфа о предмете. Значит отдельно сохраняется предмет. Там БД, по любому, но с какой структурой?

23 Ноя 2019

Первая рабочая идея: пойти в лоб, сохранять в БД записи с составным ключом: мой ИД + его ИД = наш ИД.
По уникальному ключу "наш ИД" можно тянуть инфу.
НО, для 100 игроков это уже почти 10 тысяч записей в БД. Ну, хотя бы работает, уже что то.

 

[fantom]

НО, для 100 игроков это уже почти 10 тысяч записей в БД

И что? Базы расчитаны на куда большый обьем информации. Конешно если у вас шаред говнохостинг, то оно начнет либо упиратся в лимиты по обьему или памяти. Но в целом ничего в этом плохого нету

 

[Ayk]

fantom, ну, не знаю, на 1000 игроков уже 1 миллион записей.
А так, по сути, решение самое примитивное, от того и самое неоптимизированное.
Надеюсь, что знающие люди подскажут что то получше.

 

[fantom]

Ayk, наоборот, если грамотно описать связи, индексы и запросы, то это будет куда быстрее чем перебор вручную

 

[kucklovod]

Ayk, в отдельную страницу запиши стим айди игрока и дату последнего входа. записи тех, кто не заходит больше какого-то кол-ва дней, удаляй. можешь кроном, можешь в plugin_init. это как вариант, возможно заинтересует.

 

[Ayk]

kucklovod, ты слишком усложняешь. В данной задаче очистка БД никогда не была проблемой. Записи должны иметь таймстамп последнего обновления. Старые записи удаляются по этому таймстампу.

fantom, про "перебор вручную" не понял. Это о чем?
Т.к. нужен уникальный комбинированный ключ, его получаем слиянием двух стим ид. Можно взять хеш результата.
Но, как ни крути, ключ остаётся строкой (в БД будет unique). Для какого либо инт ключа, мне кажется, коллизия имеет больший %.
Вот и имеем поиск строки среди миллионов записей.
Что можно оптимизировать в данном случае?

Ни у кого нет других идей по данному вопросу?

 

[kucklovod]

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

 

[voed]

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

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

 

[Sonyx]

Вот и имеем поиск строки среди миллионов записей.
Что можно оптимизировать в данном случае?

Нормализовать таблицу, вынести STEAM_ID в отдельную с присвоением Primary, в основной делать составной ключ из 2 столбцов attacker_id, victim_id

25 Ноя 2019

Главное - victim_id и attacker_id - это 2 РАЗНЫХ столбца, не додумайтесь их писать в один). В дальнейшем при выборке по игроку, получаем из второй таблицы id игрока, по id выбираем все дуэли

 

[zhorzh78]

Вот и имеем поиск строки среди миллионов записей.
Что можно оптимизировать в данном случае?

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

 

[Ayk]

voed, что считать дуэлью на паблике или ДМ-е?
Sonyx, так?

CREATE TABLE stats(
   steam_id_1 VARCHAR(35),
   steam_id_2 VARCHAR(35),
   player1_kills INT,
   player2_kills INT,
   ...,
   PRIMARY KEY(steam_id_1,steam_id_2)
);

SELECT * FROM stats WHERE steam_id_1 = '%s' AND steam_id_2 = '%s';

zhorzh78, нет, спасибо.

 

[fantom]

Ayk, создайте таблицу игроков (ид, стим ид) и дуелей (ид1, ид2, ....) и все. Подробности узнайтев статьях про нормализацию БД.

 

[voed]

@voed, что считать дуэлью на паблике или ДМ-е?

Дуэль - убийство, что же еще?

 

[Ayk]

fantom, так?

CREATE TABLE players(
   id INT AUTO_INCREMENT PRIMARY KEY,
   steam_id VARCHAR(35) NOT NULL UNIQUE
);
CREATE TABLE stats(
   attacker_id INT,
   victim_id INT,
   attacker_kills INT,
   victim_kills INT,
   ...,
   PRIMARY KEY(attacker_id, victim_id)
);

Можно улучшить?

voed, и что в итоге? Если не затруднит, покажи sql код таблиц.
Чтобы узнать сколько раз игрок А убил игрока Б придётся пройтись по всем записям и посчитать количество тех в которых А фигурирует как убийца и Б как жертва?

 

[kucklovod]

Ayk, как-то глупо составил структуру базы. достаточно записать ид1, ид2, килл1, килл2. собственно, при убийстве первого вторым, добавлять второму +1. теперь ты знаешь, что второй был 1 раз убийца, а первый 0. если тебе нужны смерти, то добавь деад1, деад2. при убийстве первого вторым, добавляешь +1 к деад1.

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

для вывода используй SELECT запрос, в котором укажи WHERE id1 = ... AND id2 = ... . в каллбеке получишь результат, а там уже выведешь нужную инфу

 

[Ayk]

kucklovod, свой код покажи, перед тем как что то глупым называть.

 

[zhorzh78]

Параноики..

 

[CrazyHackGUT]

ид1, ид2, килл1, килл2

Ужас какой у Вас с именованием колонок. Но мыслите верно.


У игрока, конечно, никнейм и др. может и не храниться. Но сама суть думаю ясна.

 

[kucklovod]

CrazyHackGUT, благодарю. писал с телефона, было неудобно очень. хотел как можно быстрее донести мысль

 

[Ayk]

А чем это отличяется от того что я показал?