Хранение в БД.

@--Rand-- · Регистрация: 09.07.2009

Студворк — интернет-сервис помощи студентам

Пишу бой для онлайн игры (своей для развлечения) на PHP. Естественно у боя бывает Лог. Так вот не могу никак врубиться в его хранение в БД. допустим:

игрок А ударил Игрока Б -5
Игрок Б ударил, но игрок А заблокировал

теперь это надо сохранить в БД (ну всмысле по мере нанесения ударов, это сохраняется в БД и сразу же отображается).
Помогите набросать структуру таблицы, где храняться эти записи.

@mamedovvms · 28.10.2009, 13:29

может стоить хранить не эти записи а то на что они влияют например жизнь

@--Rand-- · 28.10.2009, 13:47 **[ТС]**

Сообщение от mamedovvms

может стоить хранить не эти записи а то на что они влияют например жизнь

Ну сам Лог боя ведь должен быть. А насчет жизнь и т.д это будет но в другой таблицею Мне именно с логами что делать не знаю

@Deicider · 28.10.2009, 16:28

Предлагаю следующую структуру:
id | who | what | response

id – номер действия, он же будет ключом таблицы
who – кто сделал действие (писать сюда игрок А или Б)
what – что именно сделал (ударил, порезал, выстрелил и пр.)
response – противодействие (то есть, как у тебя в примере, если игрок заблокировал, то вносить это в эту колонку)

@--Rand-- · 28.10.2009, 19:39 **[ТС]**

Предлагаю следующую структуру:
id | who | what | response

id – номер действия, он же будет ключом таблицы
who – кто сделал действие (писать сюда игрок А или Б)
what – что именно сделал (ударил, порезал, выстрелил и пр.)
response – противодействие (то есть, как у тебя в примере, если игрок заблокировал, то вносить это в эту колонку)

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

@motakuji · 29.10.2009, 10:33

Сообщение от --Rand--

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

Согласен,ведь в одно и тоже время могут проводиться десятки боёв...Думаю,что нужно создать столбец с ключом(id) самого боя...Можно сделать след:
id | who | whom | action | log_id

Потом с этой таблицей легко работать...В id прописывается ключ со значение auto_incriment дальше я думаю,что всё понятно...Что нам это даст...В поле логе просто вставляем все элементы таблицы,где log_id= идентификатору нашего боя...После окончания боя,если хочешь удалить все записи этого боя,просто сделай удаление всех записей в таблице,где log_id=идентификатору этого боя...Хотя во многих он-лайн играх все логи сохраняются...Предлагаю сделать следующее: создать ещё 1 поле с датой,когда был начат этот бой...И через определённое время,например неделю,или месяц,удалять все записи,в которых в этом поле значение меньше нынешней даты на определённое кол-во дней...уникальный идентификатор для боя можно создать с помощью функции uniqid(),кот создаёт его на основе текущего времени...

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

@Deicider · 29.10.2009, 15:12

Сообщение от --Rand--

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

ну эта структура подходит, если на каждый бой будет отдельная таблица. Если всё вперемешку, тогда действительно, как написал motakuji, добавляется столбец с ID боя.

@--Rand-- · 29.10.2009, 15:25 **[ТС]**

Ну это мне ясно..меня другое волнует !

Например ! Записал в БД

id 3
who игрокА
whom игрокБ
action ударил -150, заблокировал в нос.
log_id 3

Таких записей будет допустим 100 и каждая со своим идентификатором, как их потом соединить...если id у всех разные ????? В этом моя проблема, а не в том как вставить и что извлечь.

К тому же одновременно может быть допустим 20 боев, 100 боев на сервере...запись на запись будет лезть...их ведь потом не найдешь...чтоб извлечь.

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

@Deicider · 29.10.2009, 15:26

Соединить элементарно!
SQL-запрос: SELECT * FROM table WHERE log_id=...

получаешь таким образом выборку всех строк, относящихся к конкретному бою. Тут уже не важно, что параллельно в таблицу писалось хоть 1000 боев

@motakuji · 29.10.2009, 15:29

зачем разный? разный будет только id-это уникальный идентификатор записи в таблице..Вот к примеру
id | who | whom | action | log_id
1 |Игр1 |Игр2 |Ударил150| 1
2 |Игр2 |Игр1 |Удар -200|1
3 |Игр1 |Игр2 |Удар -100|1
и т.д. log_id ты сам вписываешь,а не автоматом... Вот и всё)) вотом делаешь выборку типа

SQL
1
SELECT * FROM logs WHERE log_id=1

и он тебе все эти записи выдаст.
У следующего боя пропишешь в log_id 2 и т.д.

@--Rand-- · 29.10.2009, 15:32 **[ТС]**

зачем разный? разный будет только id-это уникальный идентификатор записи в таблице..Вот к примеру
id | who | whom | action | log_id
1 |Игр1 |Игр2 |Ударил150| 1
2 |Игр2 |Игр1 |Удар -200|1
3 |Игр1 |Игр2 |Удар -100|1
и т.д. log_id ты сам вписываешь,а не автоматом... Вот и всё)) вотом делаешь выборку типа
Код SQL

1

SELECT * FROM logs WHERE log_id=1

и он тебе все эти записи выдаст.

Вот уже становится яснее

Просто я присваиваю какое-то значение log_id, а потом по ниму ищу ???

Спасибо, самое главное вы дали нужное направление !!!

@Yunus · 24.03.2010, 13:59

игрок А ударил Игрока Б -5
Игрок Б ударил, но игрок А заблокировал

id | time | text | log_id

text - сюда HTML код, только со слешами \"

все гениально и просто, лично я так делал аналог лога боя игры Carnage

@Archusha · 24.03.2010, 14:23

Занимался подобными системами (играми), вот что могу сказать. Если подразумевается лог боя аля:
Боец 1 ударил по колленной чашечке Бойца 2, переломив ему межреберную кость -25 ХП.
то лучше хранить этот лог ввиде HTML кода.
Тоесть в конце каждого хода (когда прошел размен) в файл дописывать строчку.

Здесь есть огромное приимущества в том, что когда ты из БД будеш выдергивать по ИД боя данные, через какое то время это превратится в мучительную операцию для БД. Поэтому проще когда человек открывает лог боя инклудить ему файл (название которого является номер лога) хтмл.

При этом сценариев в файле нет и по сути это вывод хтмл страницы.

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

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

@Yunus · 24.03.2010, 20:45

ты хоть в курсе сколько таких файлов накопиться за 1 год в твоей папке? у меня логи записывались в файлы но сервак тупил. Для нормальных логов без MySql не обойтись!!!!! Чел же помощи просил не зря, вот я ему и дал совет как записывать не в файл а в базу не меняя кода.

@SunDrop · 24.03.2010, 23:54

Сообщение от Archusha

по ИД боя данные, через какое то время это превратится в мучительную операцию для БД.

Или вы на БД не пользовались индексами или была криво составлена база.
У меня база статистики на 3,5 млн. записей - реальная статистика за год сайта с посещаемостью около 10 тыс человек в сутки... И оптимизированные выборки нормально обрабатывались. И на тот момент это был MyISAM, а не INNODB! Так что, не верю я что при наличии индекса по полю log_id будут какие-то проблемы.

@Yunus · 25.03.2010, 11:51

он просто написал того чего сам не знает.

Archusha иди изучи работу MySQL, с воздуха ненужно брать типа если база большая то она обязательно должна тупить. ИНДЕКСАЦИЯ и еще раз ИНДЕКСАЦИЯ!!!
Вот сейчас я пишу в форум и мое сообщение записывается в базу но сервер же не тупит из-за того что тут миллионы людей отписываются.

Новые блоги и статьи Все статьи Все блоги /
Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .	Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .	Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .
Кому нужен AOT? DevAlt 26.03.2026 Решил сделать простой ланчер Написал заготовку: dotnet new console --aot -o UrlHandler var items = args. Split(":"); var tag = items; var id = items; var executable = args;. . .	Отправка уведомления на почту при создании или изменении элементов справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной записи электронной. . .	модель ЗдравоСохранения 5. Меньше увольнений- больше дохода! anaschu 24.03.2026 Теперь система здравосохранения уменьшает количество увольнений. 9TO2GP2bpX4 a42b81fb172ffc12ca589c7898261ccb/ https:/ / rutube. ru/ video/ a42b81fb172ffc12ca589c7898261ccb/ Слева синяя линия -. . .	Midnight Chicago Blues kumehtar 24.03.2026 Такой Midnight Chicago Blues, знаешь?. . Когда вечерние улицы становятся ночными, а ты не можешь уснуть. Ты идёшь в любимый старый бар, и бармен наливает тебе виски. Ты смотришь на пролетающие. . .

@mamedovvms 2923 / 844 / 324 Регистрация: 30.04.2009 Сообщений: 2,633
	28.10.2009, 13:29
	может стоить хранить не эти записи а то на что они влияют например жизнь 0

@Deicider 98 / 54 / 3 Регистрация: 18.03.2009 Сообщений: 273
	28.10.2009, 16:28
	Предлагаю следующую структуру: id \| who \| what \| response id – номер действия, он же будет ключом таблицы who – кто сделал действие (писать сюда игрок А или Б) what – что именно сделал (ударил, порезал, выстрелил и пр.) response – противодействие (то есть, как у тебя в примере, если игрок заблокировал, то вносить это в эту колонку) 1

@--Rand-- 1 / 1 / 0 Регистрация: 09.07.2009 Сообщений: 93
	29.10.2009, 15:25 [ТС]
	Ну это мне ясно..меня другое волнует ! Например ! Записал в БД id 3 who игрокА whom игрокБ action ударил -150, заблокировал в нос. log_id 3 Таких записей будет допустим 100 и каждая со своим идентификатором, как их потом соединить...если id у всех разные ????? В этом моя проблема, а не в том как вставить и что извлечь. К тому же одновременно может быть допустим 20 боев, 100 боев на сервере...запись на запись будет лезть...их ведь потом не найдешь...чтоб извлечь. Насчет хранения...так мне оно и нужно !! чтоб лог боя был доступен и после боя, еще дней 10 например. Просто выводить записи я и без БД могу..аяксом например. 0

@Deicider 98 / 54 / 3 Регистрация: 18.03.2009 Сообщений: 273
	29.10.2009, 15:26
	Соединить элементарно! SQL-запрос: SELECT * FROM table WHERE log_id=... получаешь таким образом выборку всех строк, относящихся к конкретному бою. Тут уже не важно, что параллельно в таблицу писалось хоть 1000 боев 1

@Archusha 5 / 5 / 1 Регистрация: 23.08.2009 Сообщений: 33
	24.03.2010, 14:23
	Занимался подобными системами (играми), вот что могу сказать. Если подразумевается лог боя аля: Боец 1 ударил по колленной чашечке Бойца 2, переломив ему межреберную кость -25 ХП. то лучше хранить этот лог ввиде HTML кода. Тоесть в конце каждого хода (когда прошел размен) в файл дописывать строчку. Здесь есть огромное приимущества в том, что когда ты из БД будеш выдергивать по ИД боя данные, через какое то время это превратится в мучительную операцию для БД. Поэтому проще когда человек открывает лог боя инклудить ему файл (название которого является номер лога) хтмл. При этом сценариев в файле нет и по сути это вывод хтмл страницы. При этом так же не сложно сделать и пролистование страниц, работая напрямую со строками или обозначая размен спец тегом. а если ты просто имееш ввиду лог кто, куда ударил, то лучше хранить его в БД до окончания боя, а после окончания боя выгружать эти данные опять же в ХТМЛ файл. 0

@Yunus 0 / 0 / 0 Регистрация: 24.03.2010 Сообщений: 3
	24.03.2010, 20:45
	ты хоть в курсе сколько таких файлов накопиться за 1 год в твоей папке? у меня логи записывались в файлы но сервак тупил. Для нормальных логов без MySql не обойтись!!!!! Чел же помощи просил не зря, вот я ему и дал совет как записывать не в файл а в базу не меняя кода. 0

@Yunus 0 / 0 / 0 Регистрация: 24.03.2010 Сообщений: 3
	25.03.2010, 11:51
	он просто написал того чего сам не знает. Archusha иди изучи работу MySQL, с воздуха ненужно брать типа если база большая то она обязательно должна тупить. ИНДЕКСАЦИЯ и еще раз ИНДЕКСАЦИЯ!!! Вот сейчас я пишу в форум и мое сообщение записывается в базу но сервер же не тупит из-за того что тут миллионы людей отписываются. 0