SA-MP Forums Archive
[Making Logs]MySQL vs Text Files for Performance - Printable Version

+- SA-MP Forums Archive (https://sampforum.blast.hk)
+-- Forum: SA-MP Scripting and Plugins (https://sampforum.blast.hk/forumdisplay.php?fid=8)
+--- Forum: Scripting Help (https://sampforum.blast.hk/forumdisplay.php?fid=12)
+---- Forum: Discussion (https://sampforum.blast.hk/forumdisplay.php?fid=84)
+---- Thread: [Making Logs]MySQL vs Text Files for Performance (/showthread.php?tid=600877)



[Making Logs]MySQL vs Text Files for Performance - Yashas - 14.02.2016

At the very outset, I would like to say that I am solely worried about performance and not about the productivity or applications of using either of the systems.

Concerns while using text files: Advantages of using text files: Concerns while using MySQL: Advantage of using MySQL: Maybe the topic is too general? Should I have two types of logs? A log where insertion is done almost every second and a log where insertion is done once every minute?

What if you wanted to log commands used by players?
What if you wanted to log punishments (warn, kick, ban)?


Give your opinions and I shall keep adding every new advantage & disadvantage suggested to my list.


Re: [Making Logs]MySQL vs Text Files for Performance - ]Rafaellos[ - 14.02.2016

I had this concern a week ago and I think, it's better to use both options. What I Mean?

Splitting important things that you want to log with the less-important. Important goes to MySQL and less ones go to txt.

Let me explain it more:

Let's say I want to create a command that shows the last let's say 10 reports. It's much easier to do it using MySQL and the most important you can find how many times a certain player got reported without creating a new row for that.

But, logging chat or something similar, it would be pointless using MySQL because there is no use in it anyway. You just download it using filezilla or something, check for any threat or something and you delete it for a refresh.

I hope you got my point, my English suck a little, have a nice day!


Re: [Making Logs]MySQL vs Text Files for Performance - maddinat0r - 14.02.2016

JernejL once made a threaded fwrite plugin: https://sampforum.blast.hk/showthread.php?tid=286453

And I guess the big advantage of text files is their more natural use. You just have to open that file with your favorite text editor and you're ready to go, while for MySQL you need to use the MySQL client and write your own queries to access the log data.


Re: [Making Logs]MySQL vs Text Files for Performance - AmigaBlizzard - 14.02.2016

Samp-server is already logging everything to a text file ("server_log.txt").

If you want to log anything, just use a printf statement and it's in there.
Normal chat logs automatically to that log-file, so it has no use to create extra code to log it a second time in a different file.

I'm using MySQL to log most of my stuff.
Why?
You can easily filter stuff out.

I have one table that records every player-login.
It records the timestamp when a player logged in, his ID (unique integer that defines this player) and his IP at that time.

When this player would complain that his account has been hacked, I can easily filter out all his logins and check the IP.
If the IP has a different range all of a sudden (usually the last digits could be a little different for this player's main location), you can be sure his account has been hacked from another location.

Using Navicat, you can sort data in a nice table on your screen and use custom SELECT queries to filter out data.

Doing the same using textfiles requires alot more work to find the data you're looking for, unless you have textfiles for every situation and every player separately.


Re: [Making Logs]MySQL vs Text Files for Performance - Slice - 14.02.2016

Personally, I use SQLite with synchronous OFF.

It's fast enough and allows me to add more metadata such as categories and tags.

The main issue with fwrite is that the I/O is blocking. Creating a string with date/time or casting a string to a C-string is negligible, and changing your code just because of that is bad practice.