Вид для печати
Здравствуйте, уважаемые пользователи. Подскажите, как можно реализовать систему логирования для каждого игрока?
К примеру, игрок: Pro_Pawn.
Игрок заходит в магазин и покупает там телефон, который стоит 450$.
соответственно в scriptfiles должен появиться файл Pro_Pawn.ini и там должно быть
21.06.0017 - 17:57:40 - покупка ( -450 вирт ) ( было: 450 вирт, стало: 0 вирт )
- - - Добавлено - - -
или как-то на мускул можно?
Собственно юзаете log(ваш текст) там, где нужноPHP код:
log( text[] ) {
new File: handle = fopen("file.txt", io_append) ;
fwrite( handle, text ) ;
fclose( handle );
}
На MySQL проще и лучше. Просто создаёшь 2 таблицы: одна для перечисления типов логирования, а вторая для самих логов.
Структура первой таблицы:
Например:PHP код:log_type_id | log_type_name
log_type_id //- AUTO_INCREMENT
log_type_name //- название для типа логирования
log_type_id log_type_name 1 Покупка телефона 2 Передача денег 3 Продажа авто
А уже вторая таблица будет иметь столько столбцов, сколько тебе нужно будет. Но вот основные:
Сюда же можешь добавить количество денег на руках при каждом случае и прочую инфу, которая тебе пригодится в отдельном виде.PHP код:id | account_id | log_type_id | log_message | log_date
id //- AUTO_INCREMENT
account_id //- ID игрока, которого логируем
log_type_id //- ID типа логов, которые берём из первой таблицы
log_message //- сам текст сообщения (то самое "покупка ( -450 вирт ) ( было: 450 вирт, стало: 0 вирт )")
log_date //- дата логирования
Первая таблица нужна для удобства извлечения данных из второй таблицы (можешь конечно её не создавать и держать все типы логов в голове, но потом самому будет неудобно вспоминать какой тип что означает).
Собственно, заполнение происходит обычным INSERT запросом
Спасибо всем!
Таблица для нескольких типов? Зачем? Я не думаю, что они у него будут добавляться со скорость летящего самолета. Хорошо, если 1 в месяц (Цитата:
Сообщение от DeimoS
это для уже работающего проекта ). А так их может быть всего 10-15. Советую не делать, как сказал деймос.
Только так делать и надо. И что, что будет 10-15 типов, какое это имеет значение? Без присвоения логам типов, ты не сможешь нормально их сортировать (придётся писать тяжёлые запросы, парсящие строки).Цитата:
Сообщение от Fallen A.
Хотя, я бы, наверное, добавил ещё поле вроде log_data_id (типа как здесь) + ассоциативную таблиц для связи. Тогда появилась бы возможность для каждой записи в лог добавлять дополнительную информацию, например: кому передали деньги (id аккаунта), сколько и где. С подобной информацией поиск по логам стал бы очень простым, плюс появилась бы возможность создавать всякие статистики.
Ты, видимо, меня не понял, раз так говоришь. Ничего парсить не нужно.Цитата:
Сообщение от ziggi
На самом деле на эту систему можно накручивать и накручивать функционал, который сделает её лишь удобнее, чем я и советовал бы заняться автору. И, в том числе, следует отказаться от дополнительных столбцов во второй таблице и создать для этого дела третью (в общем, то, что сказал Ziggi)Цитата:
Сообщение от ziggi
Придётся держать название типов в голове, мы поняли. Я об этом варианте писал ещё в предыдущем сообщении же. И так же намекал, что это неудобно.Цитата:
Сообщение от Fallen A.
Собственно, что тебя напрягает в дополнительной таблице? Точнее, какой профит от того, что ты откажешься от неё? Сэкономишь пару килобайт на жестком диске хостинга? Или у тебя какое-то ограничение по количеству таблиц предъявляет хостинг? В чём проблема?
Можно, конечно, хранить названия типов в массиве, но плюс отдельной БД в том, что благодаря ей можно обращаться к основной таблице по названию типа, а не по ID типа, просто составив вложенный запрос, а-ля
Что может существенно облегчить написания серверной составляющей всей системы (например, можно вывод логов в виде диалогового окна написать довольно просто и понятно).PHP код:SELECT * AS ls FROM log_type_list AS lt, log_system WHERE lt.log_type_name = 'тут_название_типа' AND ls.log_type_id = lt.log_type_id
// Этот запрос далеко не идеален и не факт, что будет работать, но и не суть. Основная мысль: достать данные по названию типа используя лишь один запрос и ничего более. Это упростит написание системы, а значит уменьшит шанс допустить ошибку при её написании, что сэкономит вам время
То бишь, глупо усложнять себе жизнь ради экономии мизерного пространства, что займёт эта таблица.
Не в голове. Каждому свое.Цитата:
Сообщение от DeimoS
Так а где же ещё? Если выделять массив под это дело, то придётся со стороны сервера писать скрипт, который бы сопоставлял названия и выдавал ID типа, что лишь усложнит код и нагрузит основной поток.Цитата:
Сообщение от Fallen A.
А что мешает использовать статик?Цитата:
Сообщение от DeimoS
Причём тут статик? О_оЦитата:
Сообщение от Fallen A.
Записывать в статик тип лога. Нет?Цитата:
Сообщение от DeimoS
И что это изменит? Прочти ещё раз мои сообщения и скажи как твой статик изменит ситуациюЦитата:
Сообщение от Fallen A.
В таком случае прочти все мои сообщения и пойми то, о чем ты ведешь речь.Цитата:
Сообщение от DeimoS
Я-то как раз понимаю о чём веду речь. Понимаю, что гораздо лучше напрячь базу данных, если вдруг решу определять тип логов по названию, нежели на стороне сервера делать проверку. А вот ты почему-то не особо понимаешь какие возможности привнесёт таблица, кроме, собственно, создания этой само таблицы.Цитата:
Сообщение от Fallen A.
Ты еще раз подтвердил то, что не понимаешь, о чем говорю я.Цитата:
Сообщение от DeimoS
Никто не понимает, а, значит, и ты сам.Цитата:
Сообщение от Fallen A.
Так объясни тогда нормально что ты хочешь предложить (можно даже набросками кода, раз словами не можешь), ибо, как уже сказали выше, никто не понимает о чём ты тут говоришь.Цитата:
Сообщение от Fallen A.
- - - Добавлено - - -PHP код:const MODE_MONEY = 0,
MODE_KILL = 1,
MODE_SPAWN = 2,
MODE_USE = 3;
Если никто не понимает теорию относительности, это не значит, что ее не понимает автор. У тебя глупый вывод.Цитата:
Сообщение от ziggi
Тут, скорее, ты не можешь понять о чём говорим мы -_-Цитата:
Сообщение от Fallen A.
Повторяю в сотый раз. Вот я захотел сделать функцию, которая возволит создавать лог по названию типа, а-ля:
Как в этом случае помогут твои константы? -_-PHP код:WriteLog(playerid, "Пополнение счёта", ...);
И да, не нужно тут писать "зачем это нужно?".
Во-первых, это лишь элементарный пример. При желании, можно, например, сделать простой вывод данных из логов в виде простого диалога и автоматизировать всю систему
Открыть/закрыть
Во-вторых, работать с нормальными названиями (при том на русском) всегда проще, нежели с именами констант. Как минимум, потому, что они синтаксически выделяются.
Если бы ты понимал, то ты бы смог это объяснить любому. С теорией относительности всё точно так же.Цитата:
Сообщение от Fallen A.
И что? Как это относится к хранению логов в БД?Цитата:
Сообщение от Fallen A.
Я пояснил это так, как и хотел.Цитата:
Сообщение от ziggi
- - - Добавлено - - -
Прекрасно понимаю, поэтому советую автору сортировать логи относительно их типа. А этот тип хранить в БД не имеет смысла, лично для меня. Несколько строк кода вручную - не проблема.Цитата:
Сообщение от DeimoSТут, скорее, ты не можешь понять о чём говорим мы -_-
Повторяю в сотый раз. Вот я захотел сделать функцию, которая возволит создавать лог по названию типа, а-ля:
Как в этом случае помогут твои константы? -_-PHP код:WriteLog(playerid, "Пополнение счёта", ...);
И да, не нужно тут писать "зачем это нужно?".
Во-первых, это лишь элементарный пример. При желании, можно, например, сделать простой вывод данных из логов в виде простого диалога и автоматизировать всю систему
Во-вторых, работать с нормальными названиями (при том на русском) всегда проще, нежели с именами констант. Как минимум, потому, что они синтаксически выделяются.
Затем ты можешь просто отсортировать необходимые логи по их типу, лол.
Так а где ты предлагаешь держать ID этого типа и как ты предлагаешь автоматизировать всю систему?Цитата:
Сообщение от Fallen A.
То, что для тебя не имеет смысла делать код более гибким и удобным, не означает, что этот код теряет свои свойства из-за этого.
И то, что ты предлагаешь жертвовать процессорным временем ради того, чтоб хранить данные о типах данных не в таблице, а в amx, тоже не делает твой вариант лучше.
А типы-то он где будет брать? Держать их в голове? Или делать кучу костылей в виде информационных диалогов с нумерацией этих типов, что займут больше места, чем одна база данных?Цитата:
Сообщение от Fallen A.
Кто тебе вообще сказал, что таблица обязательно должна содержать много данных и эти данные должны постоянно обновляться?
Сортировка по типу будет занимать больше места? Лол.
Процессорное время увеличится на 0.0000... Тебя это так беспокоит?
Мдам-с.
Я не предлагал автоматизировать систему, а предлагал хранить типы не в БД. Все.
Да. Тебе нужно как-то эти типы обозначить в коде, не? Сначала константы, потом написать диалоговое окно, где вручную обозначить название каждого типа диалогов, а потом ещё и написать обработчик этого самого диалога. Не говоря про остальные тонкости, что потребуются при хранении данных на стороне мода.Цитата:
Сообщение от Fallen A.
Когда в случае с таблицей нужно лишь просто загрузить данные в массив и после отправить текст из диалога в запросе. Всё. Никаких циклов и никаких танцев с бубном.
А теперь иди и сделай тест, создав одну таблицу с 10 значениями и один массив с 10 значениями (все значения - названия строк), а после попробуй сделать поиск последнего значения и отправку номера этого значения в БД. То бишь, воссоздай две системы и посмотри какое там будет увеличение.Цитата:
Сообщение от Fallen A.
И ради чего? Ради того, чтоб сэкономить память на MySQL сервере. Логично ты ресурсы распределяешь, да...
Ты предлагаешь сделать систему менее гибкой и менее удобной, мы это поняли. Только ты так и не объяснил почему ты не хочешь хранить типы в БД.Цитата:
Сообщение от Fallen A.
Не указывай мне, что делать и не узнаешь, куда будешь послан.Цитата:
Сообщение от DeimoS
Пфффффф... 1 запрос на поиск последнего значения и еще один на вставку в БД. Точно так же, как и у тебя.
Увеличение будет точно такое же, как и у тебя опять же. Не удивил.
И да, просмотр системы логирования в моде? Оо, ну ты и извращенец. У меня для этого есть веб часть.
А ты не делай необоснованных высказываний и тебя никто не будет посылать.Цитата:
Сообщение от Fallen A.
О вложенных запросах не слышал? Так почитай. MySQL такие запросы даже лучше переваривает, чем 2 отдельных запроса (ну если они правильно построены, ествественно). Я тебе про это ещё в 8-ом сообщении этой темы писалЦитата:
Сообщение от Fallen A.
Извращенец тут только ты, если не можешь написать простой скрипт, который вытянет для тебя КОНКРЕТНУЮ информацию из всех логов. Если ты держишь логи на MySQL и, при этом, все целиком их просматриваешь, вручную выискивая информацию - ...Цитата:
Сообщение от Fallen A.
Ну я уже сказал кто ты тогда ;)
Спасибо, но в курсе. И да, если ты меня не понял, это не значит, что можно ссылки присылать.Цитата:
Сообщение от DeimoS
Ну так о каких тогда двух запросах идёт речь?Цитата:
Сообщение от Fallen A.
И чем тебя так оскорбила ссылка, лол?
А так же я хочу заметить, что я не экстрасенс и не могу понять что ты имеешь ввиду, если ты не объяснил этого. Уж извини, но такой вот у меня недостаток имеется. Видимо, совсем как Окстайл стал, да...
Склейка - это, как ни крути, все равно 2 запроса :( А я указал последовательность ее.Цитата:
Сообщение от DeimoS
Какая склейка? Ты открывал ссылку, которую я тебе кинул? -_- Там есть один запрос, в котором используется 2 оператора: INSERT и SELECT. Ни о каких двух запросах речи не идёт. И MySQL такой запрос будет обрабатывать совершенно иначе, нежели просто 2 запроса.Цитата:
Сообщение от Fallen A.
Я знаю, о чем ты говоришь. Но а я тебе говорю, что каждый подзапрос будет выполняться самостоятельно. Почему-то авторитетные ребята с хабра именно так и считают.Цитата:
Сообщение от DeimoS
Никак иначе он обрабатываться не будет.
Так а теперь ты прочти мои предыдущие сообщения.Цитата:
Сообщение от Fallen A.
Хотя давай я лучше сделаю тебе краткий пересказ основного: не лучше ли напрячь обработкой данных базу данных, которая работает в отдельном запросе, позволив серверу заниматься своими делами, нежели каждый божий раз напрягать сервер? И хочу напомнить, что запись логов происходит довольно часто. И те самые 0.002 миллисекунды в перспективе дают приличный такой застой. И у тебя есть вариант, который избавит от этого застоя, но ты от него отказываешься просто потому что. Не кажется это нелогичным?
Подожди, а при чем здесь мультипоточность? Все и так будет выполняться в том потоке, в каком ты указал.Цитата:
Сообщение от DeimoS
Ты, видимо, не понимаешь, что я хочу до тебя донести. Запросы будут идти все равно в отдельном потоке, а вставка в БД будет выполняться согласно типу лога, какой указывается из static.
Пример:
В итоге все выглядит как: игрок 2 передал игроку один 5к баков. Сортировка идет согласно LOG_TYPE. Так при чем здесь мультипоточность?PHP код:const LOG_TYPE_MONEY 1;
INSERT INTO `logs` ( `owner_id`, `sender_id`, `type`, `count` ) VALUES ( '1', '2', 'LOG_TYPE_MONEY', '5000' )
Во-первых, хранить тип лога в виде текста для каждой строки - крайне сомнительное удовольствие как по части памяти (вместо 1 символа будет записываться 10), так и по части выборки данных из такой таблицы (ты думаешь, просто так люди придумали создавать столбец, который будет хранить номер строки в виде числа, по которому происходит большинство обращений к строкам? Сравнить 2 числа гораздо проще и быстрее, нежели 2 строки).Цитата:
Сообщение от Fallen A.
Во-вторых, даже если ты обозначил так вставку содержимого константы в строку (непонятно, правда, зачем ты тогда выделил число апострофами), всё ещё стоит вопрос о том, что гораздо проще запомнить: текст капсом, что написан на английском или текст на русском?
Смотри как можно сделать проще и удобнее:
И использование:PHP код:stock WriteLogByTypeName(type_name[], account_id, log_message[])
{
static
string[159+11+MAX_LOG_MESSAGE+MAX_LOG_TYPE+1];
string[0] = '\0';
format(string, sizeof(string),
"\
INSERT INTO log_system (account_id, log_type_id, log_message, log_data) \
SELECT %d, lt.log_type_id, '%s', NOW() FROM log_type_list as lt WHERE lt.log_type_name = '%s'\
",
account_id,
log_message,
type_name);
mysql_tquery(MySQL:handle, string, "", "");
return 1;
}
И не нужно запоминать никаких LOG_TYPE_MONEY и прочего треша. Привычные слова, которые отражают суть, гораздо проще держать в памяти, нежели имена констант.PHP код:WriteLogByTypeName("Продажа авто", pInfo[playerid][pAccountID], "На руках было 100$, а стало 100100$");
Реализуй ты всё то же самое без второй таблицы, тебе придётся запускать цикл и сверять значение "type_name" со значением строк из массива, который ты создашь перед этим
Это был пример, а не кусок готового кода. Да, я записываю не текст, а 1 в тип лога.
Если ты используешь ( OMG ), русский текст для определения типа лога, то ты, явно, не имел дела с нормальными системами логирования.
INSERT and SELECT в данной системе сразу? Оо.
Этого достаточно, чтобы понять, что ты не сталкивался и придумываешь бред на ходу. Больше даже отвечать не хочу.
Алло, гараж, в таблицу с логами названия типов этих самых логов не попадают. Мне всё больше начинает казаться, что ты крайне слаб в SQL и не понимаешь о чём говоришь.Цитата:
Сообщение от Fallen A.
Вот так будет выглядеть результат
Вот этого запроса:
То бишь, запрос сам определит ID типа и подставит егоPHP код:INSERT INTO log_system (account_id, log_type_id, log_message, log_data) SELECT 5, lt.log_type_id, 'Текст логов', NOW() FROM log_type_list as lt WHERE lt.log_type_name = 'Продажа авто'
А твоих слов достаточно понять, что твои знания по части MySQL ограничиваются лишь статьями, что есть на форумах Pawn, где описывается лишь 4 типа запросов (SELECT, UPDATE, INSERT И DELETE), а дальше ты и не изучал ничего. Для тебя, наверное, будет открытием, что в запросе одновременно можно работать с неограниченными числом таблиц и что операторы можно совмещать (то, что я и сделал, собственно)Цитата:
Сообщение от Fallen A.
А твоё высказывание в чат про то, что я стал Оксом, наводит на мысли о том, что ты просто не можешь принять свою ошибку
Ага, ок.