[Django]-Logging to file vs. Logging to Database

by

1đź‘Ť

âś…

The file system can be thought of as a database as well, but here you are mainly comparing file system vs MySQL, a relational database. I would do this in the relational database for several reasons:

  • The number one reason is for simplicity. You are already using a database. I would not introduce the added complexity of using files as well. Just add a new table and be done with it.
  • Database permissions and file system permissions are often different, and you’ll need to worry about both.
  • This makes it easy to migration your application since you don’t need to move files and database.
  • You have not foreseen any filtering, yet, but your clients more than likely will request it in the future.
  • In a database, you have much better control over performance. You can’t really index a file system. Most file systems store the list of files in a file that must be scanned every time.
  • Sharding in the database is more transparent than in the file system. It’s difficult to spread files to multiple storage locations without changing the way you access them.

I don’t see any benefits to storing on the file system if you already have a relational database set up.

👤John Tseng

2đź‘Ť

so that users connected to the task can know who has done which changes

This changes the data in question from system-level logging to application-visible data. As such, it probably belongs in the application’s database. This will also make it a lot easier to filter the log data for display. For example, if you want to show all historical events for Item X then you can easily query a database table which has a foreign key relationship to the Items table. Reading in that data from a file and filtering it manually would be unnecessarily difficult.

Side note: “audit data” or perhaps “history data” might be a better term, to distinguish it from system logging such as error logs.

👤David

Leave a comment