CODEWITHSUNDEEP
mysqldjango
Parin Porecha
Parin Porecha

Reputation: 563

Logging to file vs. Logging to Database

I have a to-do list app ( using Django 1.5 and MySQL ) in which a task can be shared with another user. Thus, a user can have personal tasks and shared tasks. Shared tasks will be a fraction ( i guess around 30% of total tasks of a user )

For shared tasks, I want to keep a log so that users connected to the task can know who has done which changes. For this, I'm thinking of keeping a log file for every shared task. Whenever any user makes a change, it'll be appended to that file.

My question is - Should I do it via file storage, or should I save it in database ?

Please note these points -

Thanks in advance !

Upvotes: 3

Views: 2039

Answers (2)

John Tseng
John Tseng

Reputation: 6352

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.

Upvotes: 1

David
David

Reputation: 218837

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.

Upvotes: 2

Related Questions