Система логирования.

[admln]

Здравствуйте, уважаемые пользователи. Подскажите, как можно реализовать систему логирования для каждого игрока?
К примеру, игрок: Pro_Pawn.

Игрок заходит в магазин и покупает там телефон, который стоит 450$.
соответственно в scriptfiles должен появиться файл Pro_Pawn.ini и там должно быть

21.06.0017 - 17:57:40 - покупка ( -450 вирт ) ( было: 450 вирт, стало: 0 вирт )

- - - Добавлено - - -

или как-то на мускул можно?

[Seregamil]

log( text[] ) {
new File: handle = fopen("file.txt", io_append) ;
fwrite( handle, text ) ;
fclose( handle );
}

Собственно юзаете log(ваш текст) там, где нужно

[DeimoS]

На MySQL проще и лучше. Просто создаёшь 2 таблицы: одна для перечисления типов логирования, а вторая для самих логов.
Структура первой таблицы:

log_type_id | log_type_name

log_type_id //- AUTO_INCREMENT
log_type_name //- название для типа логирования

Например:


log_type_id
log_type_name


1
Покупка телефона


2
Передача денег


3
Продажа авто



А уже вторая таблица будет иметь столько столбцов, сколько тебе нужно будет. Но вот основные:

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 запросом

[admln]

Спасибо всем!

[Fallen A.]

На MySQL проще и лучше. Просто создаёшь 2 таблицы: одна для перечисления типов логирования, а вторая для самих логов.
Структура первой таблицы:

log_type_id | log_type_name

log_type_id //- AUTO_INCREMENT
log_type_name //- название для типа логирования

Например:


log_type_id
log_type_name


1
Покупка телефона


2
Передача денег


3
Продажа авто



А уже вторая таблица будет иметь столько столбцов, сколько тебе нужно будет. Но вот основные:

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 в месяц (
это для уже работающего проекта ). А так их может быть всего 10-15. Советую не делать, как сказал деймос.

[ziggi]

Таблица для нескольких типов? Зачем? Я не думаю, что они у него будут добавляться со скорость летящего самолета. Хорошо, если 1 в месяц (
это для уже работающего проекта ). А так их может быть всего 10-15. Советую не делать, как сказал деймос.

Только так делать и надо. И что, что будет 10-15 типов, какое это имеет значение? Без присвоения логам типов, ты не сможешь нормально их сортировать (придётся писать тяжёлые запросы, парсящие строки).

Хотя, я бы, наверное, добавил ещё поле вроде log_data_id (типа как здесь (http://pro-pawn.ru/showthread.php?15365-%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D1%8B-%D0%B2-%D0%B1%D0%B4&p=85697&viewfull=1#post85697)) + ассоциативную таблиц для связи. Тогда появилась бы возможность для каждой записи в лог добавлять дополнительную информацию, например: кому передали деньги (id аккаунта), сколько и где. С подобной информацией поиск по логам стал бы очень простым, плюс появилась бы возможность создавать всякие статистики.

[Fallen A.]

Только так делать и надо. И что, что будет 10-15 типов, какое это имеет значение? Без присвоения логам типов, ты не сможешь нормально их сортировать (придётся писать тяжёлые запросы, парсящие строки).

Хотя, я бы, наверное, добавил ещё поле вроде log_data_id (типа как здесь (http://pro-pawn.ru/showthread.php?15365-%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D1%8B-%D0%B2-%D0%B1%D0%B4&p=85697&viewfull=1#post85697)) + ассоциативную таблиц для связи. Тогда появилась бы возможность для каждой записи в лог добавлять дополнительную информацию, например: кому передали деньги (id аккаунта), сколько и где. С подобной информацией поиск по логам стал бы очень простым, плюс появилась бы возможность создавать всякие статистики.

Ты, видимо, меня не понял, раз так говоришь. Ничего парсить не нужно.

[DeimoS]

Хотя, я бы, наверное, добавил ещё поле вроде log_data_id (типа как здесь (http://pro-pawn.ru/showthread.php?15365-%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D1%8B-%D0%B2-%D0%B1%D0%B4&p=85697&viewfull=1#post85697)) + ассоциативную таблиц для связи. Тогда появилась бы возможность для каждой записи в лог добавлять дополнительную информацию, например: кому передали деньги (id аккаунта), сколько и где. С подобной информацией поиск по логам стал бы очень простым, плюс появилась бы возможность создавать всякие статистики.

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



Ты, видимо, меня не понял, раз так говоришь. Ничего парсить не нужно.

Придётся держать название типов в голове, мы поняли. Я об этом варианте писал ещё в предыдущем сообщении же. И так же намекал, что это неудобно.
Собственно, что тебя напрягает в дополнительной таблице? Точнее, какой профит от того, что ты откажешься от неё? Сэкономишь пару килобайт на жестком диске хостинга? Или у тебя какое-то ограничение по количеству таблиц предъявляет хостинг? В чём проблема?

Можно, конечно, хранить названия типов в массиве, но плюс отдельной БД в том, что благодаря ей можно обращаться к основной таблице по названию типа, а не по ID типа, просто составив вложенный запрос, а-ля

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

// Этот запрос далеко не идеален и не факт, что будет работать, но и не суть. Основная мысль: достать данные по названию типа используя лишь один запрос и ничего более. Это упростит написание системы, а значит уменьшит шанс допустить ошибку при её написании, что сэкономит вам время
Что может существенно облегчить написания серверной составляющей всей системы (например, можно вывод логов в виде диалогового окна написать довольно просто и понятно).
То бишь, глупо усложнять себе жизнь ради экономии мизерного пространства, что займёт эта таблица.

[Fallen A.]

Придётся держать название типов в голове, мы поняли.

Не в голове. Каждому свое.

[DeimoS]

Не в голове. Каждому свое.

Так а где же ещё? Если выделять массив под это дело, то придётся со стороны сервера писать скрипт, который бы сопоставлял названия и выдавал ID типа, что лишь усложнит код и нагрузит основной поток.

[Fallen A.]

Так а где же ещё? Если выделять массив под это дело, то придётся со стороны сервера писать скрипт, который бы сопоставлял названия и выдавал ID типа, что лишь усложнит код и нагрузит основной поток.

А что мешает использовать статик?

[DeimoS]

А что мешает использовать статик?

Причём тут статик? О_о

[Fallen A.]

Причём тут статик? О_о

Записывать в статик тип лога. Нет?

[DeimoS]

Записывать в статик тип лога. Нет?

И что это изменит? Прочти ещё раз мои сообщения и скажи как твой статик изменит ситуацию

[Fallen A.]

И что это изменит? Прочти ещё раз мои сообщения и скажи как твой статик изменит ситуацию

В таком случае прочти все мои сообщения и пойми то, о чем ты ведешь речь.

[DeimoS]

В таком случае прочти все мои сообщения и пойми то, о чем ты ведешь речь.

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

[Fallen A.]

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

Ты еще раз подтвердил то, что не понимаешь, о чем говорю я.

[ziggi]

Ты еще раз подтвердил то, что не понимаешь, о чем говорю я.

Никто не понимает, а, значит, и ты сам.

[DeimoS]

Ты еще раз подтвердил то, что не понимаешь, о чем говорю я.

Так объясни тогда нормально что ты хочешь предложить (можно даже набросками кода, раз словами не можешь), ибо, как уже сказали выше, никто не понимает о чём ты тут говоришь.

[Fallen A.]

const MODE_MONEY = 0,
MODE_KILL = 1,
MODE_SPAWN = 2,
MODE_USE = 3;


- - - Добавлено - - -


Никто не понимает, а, значит, и ты сам.

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

[DeimoS]

const MODE_MONEY = 0,
MODE_KILL = 1,
MODE_SPAWN = 2,
MODE_USE = 3;


- - - Добавлено - - -



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

Тут, скорее, ты не можешь понять о чём говорим мы -_-

Повторяю в сотый раз. Вот я захотел сделать функцию, которая возволит создавать лог по названию типа, а-ля:

WriteLog(playerid, "Пополнение счёта", ...);
Как в этом случае помогут твои константы? -_-

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

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

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

Никаких циклов со сверкой содержимого inputtext и массивом с названием типов. Только запрос, который перенесёт поиск нужного типа на плечи базы данных, а сервер в это время будет заниматься своими делами.

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

То бишь, ты и серверу сделаешь меньше работы, и себе. И всё благодаря одной "лишней" таблички

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

[ziggi]

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

Если бы ты понимал, то ты бы смог это объяснить любому. С теорией относительности всё точно так же.




const MODE_MONEY = 0,
MODE_KILL = 1,
MODE_SPAWN = 2,
MODE_USE = 3;


И что? Как это относится к хранению логов в БД?

[Fallen A.]

Если бы ты понимал, то ты бы смог это объяснить любому. С теорией относительности всё точно так же.



И что? Как это относится к хранению логов в БД?

Я пояснил это так, как и хотел.

- - - Добавлено - - -


Тут, скорее, ты не можешь понять о чём говорим мы -_-

Повторяю в сотый раз. Вот я захотел сделать функцию, которая возволит создавать лог по названию типа, а-ля:

WriteLog(playerid, "Пополнение счёта", ...);
Как в этом случае помогут твои константы? -_-

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

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

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

Никаких циклов со сверкой содержимого inputtext и массивом с названием типов. Только запрос, который перенесёт поиск нужного типа на плечи базы данных, а сервер в это время будет заниматься своими делами.

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

То бишь, ты и серверу сделаешь меньше работы, и себе. И всё благодаря одной "лишней" таблички

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

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

Затем ты можешь просто отсортировать необходимые логи по их типу, лол.

[DeimoS]

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

Так а где ты предлагаешь держать ID этого типа и как ты предлагаешь автоматизировать всю систему?
То, что для тебя не имеет смысла делать код более гибким и удобным, не означает, что этот код теряет свои свойства из-за этого.
И то, что ты предлагаешь жертвовать процессорным временем ради того, чтоб хранить данные о типах данных не в таблице, а в amx, тоже не делает твой вариант лучше.


Затем ты можешь просто отсортировать необходимые логи по их типу, лол.

А типы-то он где будет брать? Держать их в голове? Или делать кучу костылей в виде информационных диалогов с нумерацией этих типов, что займут больше места, чем одна база данных?

Кто тебе вообще сказал, что таблица обязательно должна содержать много данных и эти данные должны постоянно обновляться?

[Fallen A.]

Сортировка по типу будет занимать больше места? Лол.

Процессорное время увеличится на 0.0000... Тебя это так беспокоит?

Мдам-с.

Я не предлагал автоматизировать систему, а предлагал хранить типы не в БД. Все.

[DeimoS]

Сортировка по типу будет занимать больше места? Лол.

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


Процессорное время увеличится на 0.0000... Тебя это так беспокоит?

А теперь иди и сделай тест, создав одну таблицу с 10 значениями и один массив с 10 значениями (все значения - названия строк), а после попробуй сделать поиск последнего значения и отправку номера этого значения в БД. То бишь, воссоздай две системы и посмотри какое там будет увеличение.
И ради чего? Ради того, чтоб сэкономить память на MySQL сервере. Логично ты ресурсы распределяешь, да...


Я не предлагал автоматизировать систему, а предлагал хранить типы не в БД. Все.

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

[Fallen A.]

А теперь иди и сделай тест, создав одну таблицу с 10 значениями и один массив с 10 значениями (все значения - названия строк), а после попробуй сделать поиск последнего значения и отправку номера этого значения в БД. То бишь, воссоздай две системы и посмотри какое там будет увеличение.
И ради чего? Ради того, чтоб сэкономить память на MySQL сервере. Логично ты ресурсы распределяешь, да...


Не указывай мне, что делать и не узнаешь, куда будешь послан.

Пфффффф... 1 запрос на поиск последнего значения и еще один на вставку в БД. Точно так же, как и у тебя.
Увеличение будет точно такое же, как и у тебя опять же. Не удивил.

И да, просмотр системы логирования в моде? Оо, ну ты и извращенец. У меня для этого есть веб часть.

[DeimoS]

Не указывай мне, что делать и не узнаешь, куда будешь послан.

А ты не делай необоснованных высказываний и тебя никто не будет посылать.


Пфффффф... 1 запрос на поиск последнего значения и еще один на вставку в БД. Точно так же, как и у тебя.
Увеличение будет точно такое же, как и у тебя опять же. Не удивил.

О вложенных запросах не слышал? Так почитай (http://php-zametki.ru/php-nachinayushhim/108-insert-select.html). MySQL такие запросы даже лучше переваривает, чем 2 отдельных запроса (ну если они правильно построены, ествественно). Я тебе про это ещё в 8-ом сообщении этой темы писал


И да, просмотр системы логирования в моде? Оо, ну ты и извращенец. У меня для этого есть веб часть.

Извращенец тут только ты, если не можешь написать простой скрипт, который вытянет для тебя КОНКРЕТНУЮ информацию из всех логов. Если ты держишь логи на MySQL и, при этом, все целиком их просматриваешь, вручную выискивая информацию - ...
Ну я уже сказал кто ты тогда ;)

[Fallen A.]

О вложенных запросах не слышал? Так почитай. MySQL такие запросы даже лучше переваривает, чем 2 отдельных запроса (ну если они правильно построены, ествественно). Я тебе про это ещё в 8-ом сообщении этой темы писал


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

[DeimoS]

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

Ну так о каких тогда двух запросах идёт речь?
И чем тебя так оскорбила ссылка, лол?

А так же я хочу заметить, что я не экстрасенс и не могу понять что ты имеешь ввиду, если ты не объяснил этого. Уж извини, но такой вот у меня недостаток имеется. Видимо, совсем как Окстайл стал, да...

[Fallen A.]

Ну так о каких тогда двух запросах идёт речь?
И чем тебя так оскорбила ссылка, лол?

А так же я хочу заметить, что я не экстрасенс и не могу понять что ты имеешь ввиду, если ты не объяснил этого. Уж извини, но такой вот у меня недостаток имеется. Видимо, совсем как Окстайл стал, да...

Склейка - это, как ни крути, все равно 2 запроса :( А я указал последовательность ее.

[DeimoS]

Склейка - это, как ни крути, все равно 2 запроса :( А я указал последовательность ее.

Какая склейка? Ты открывал ссылку, которую я тебе кинул? -_- Там есть один запрос, в котором используется 2 оператора: INSERT и SELECT. Ни о каких двух запросах речи не идёт. И MySQL такой запрос будет обрабатывать совершенно иначе, нежели просто 2 запроса.

[Fallen A.]

Какая склейка? Ты открывал ссылку, которую я тебе кинул? -_- Там есть один запрос, в котором используется 2 оператора: INSERT и SELECT. Ни о каких двух запросах речи не идёт. И MySQL такой запрос будет обрабатывать совершенно иначе, нежели просто 2 запроса.

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

Никак иначе он обрабатываться не будет.

[DeimoS]

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

Никак иначе он обрабатываться не будет.

Так а теперь ты прочти мои предыдущие сообщения.
Хотя давай я лучше сделаю тебе краткий пересказ основного: не лучше ли напрячь обработкой данных базу данных, которая работает в отдельном запросе, позволив серверу заниматься своими делами, нежели каждый божий раз напрягать сервер? И хочу напомнить, что запись логов происходит довольно часто. И те самые 0.002 миллисекунды в перспективе дают приличный такой застой. И у тебя есть вариант, который избавит от этого застоя, но ты от него отказываешься просто потому что. Не кажется это нелогичным?

[Fallen A.]

Так а теперь ты прочти мои предыдущие сообщения.
Хотя давай я лучше сделаю тебе краткий пересказ основного: не лучше ли напрячь обработкой данных базу данных, которая работает в отдельном запросе, позволив серверу заниматься своими делами, нежели каждый божий раз напрягать сервер? И хочу напомнить, что запись логов происходит довольно часто. И те самые 0.002 миллисекунды в перспективе дают приличный такой застой. И у тебя есть вариант, который избавит от этого застоя, но ты от него отказываешься просто потому что. Не кажется это нелогичным?

Подожди, а при чем здесь мультипоточность? Все и так будет выполняться в том потоке, в каком ты указал.

Ты, видимо, не понимаешь, что я хочу до тебя донести. Запросы будут идти все равно в отдельном потоке, а вставка в БД будет выполняться согласно типу лога, какой указывается из static.

Пример:



const LOG_TYPE_MONEY 1;

INSERT INTO `logs` ( `owner_id`, `sender_id`, `type`, `count` ) VALUES ( '1', '2', 'LOG_TYPE_MONEY', '5000' )

В итоге все выглядит как: игрок 2 передал игроку один 5к баков. Сортировка идет согласно LOG_TYPE. Так при чем здесь мультипоточность?

[DeimoS]

Подожди, а при чем здесь мультипоточность? Все и так будет выполняться в том потоке, в каком ты указал.

Ты, видимо, не понимаешь, что я хочу до тебя донести. Запросы будут идти все равно в отдельном потоке, а вставка в БД будет выполняться согласно типу лога, какой указывается из static.

Пример:



const LOG_TYPE_MONEY 1;

INSERT INTO `logs` ( `owner_id`, `sender_id`, `type`, `count` ) VALUES ( '1', '2', 'LOG_TYPE_MONEY', '5000' )

В итоге все выглядит как: игрок 2 передал игроку один 5к баков. Сортировка идет согласно LOG_TYPE. Так при чем здесь мультипоточность?

Во-первых, хранить тип лога в виде текста для каждой строки - крайне сомнительное удовольствие как по части памяти (вместо 1 символа будет записываться 10), так и по части выборки данных из такой таблицы (ты думаешь, просто так люди придумали создавать столбец, который будет хранить номер строки в виде числа, по которому происходит большинство обращений к строкам? Сравнить 2 числа гораздо проще и быстрее, нежели 2 строки).

Во-вторых, даже если ты обозначил так вставку содержимого константы в строку (непонятно, правда, зачем ты тогда выделил число апострофами), всё ещё стоит вопрос о том, что гораздо проще запомнить: текст капсом, что написан на английском или текст на русском?



Смотри как можно сделать проще и удобнее:


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;
}

И использование:


WriteLogByTypeName("Продажа авто", pInfo[playerid][pAccountID], "На руках было 100$, а стало 100100$");

И не нужно запоминать никаких LOG_TYPE_MONEY и прочего треша. Привычные слова, которые отражают суть, гораздо проще держать в памяти, нежели имена констант.

Реализуй ты всё то же самое без второй таблицы, тебе придётся запускать цикл и сверять значение "type_name" со значением строк из массива, который ты создашь перед этим

[Fallen A.]

Это был пример, а не кусок готового кода. Да, я записываю не текст, а 1 в тип лога.

Если ты используешь ( OMG ), русский текст для определения типа лога, то ты, явно, не имел дела с нормальными системами логирования.

INSERT and SELECT в данной системе сразу? Оо.

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

[DeimoS]

Если ты используешь ( OMG ), русский текст для определения типа лога, то ты, явно, не имел дела с нормальными системами логирования.

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

Вот так будет выглядеть результат
http://i.imgur.com/eDSrPca.png
Вот этого запроса:

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 = 'Продажа авто'
То бишь, запрос сам определит ID типа и подставит его


INSERT and SELECT в данной системе сразу? Оо.
Этого достаточно, чтобы понять, что ты не сталкивался и придумываешь бред на ходу. Больше даже отвечать не хочу.

А твоих слов достаточно понять, что твои знания по части MySQL ограничиваются лишь статьями, что есть на форумах Pawn, где описывается лишь 4 типа запросов (SELECT, UPDATE, INSERT И DELETE), а дальше ты и не изучал ничего. Для тебя, наверное, будет открытием, что в запросе одновременно можно работать с неограниченными числом таблиц и что операторы можно совмещать (то, что я и сделал, собственно)

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

[Fallen A.]

Ага, ок.