Is it better to work directly with files or Store all contents of files into memory and edit the data from there? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

I'm currently working on a todolist system that acts like a calendar to store your Tasks and can check them off once you are done with it. We should also be able to undo our changes made.

Currently, my project mate is suggesting that we store the data into files with different dates and when we want to search for a particular task, just search whether the file exists, then edit and directly manipulate the files when needed.

However, I feel that it is better to store the data into 1 large file and load it into memory(possibly a list of tasks) when our program is executed. I can't explain why though.

Does OOP come into the picture when dealing with this?

Sorry if I am a bit confused as I am still learning.

Answer 1

Always the best practice depends on your work you are doing as for todo list you have to make multiple operation on , So its going to better if you use client side memory like a sdf file to do this instead of making files because sdf file will work as database and because its an light weight with large data to so easy to handle than file

Answer 2

It is a perfect task for a database solution. I suggest that you use the SQL server database that was included with your Visual Studio for this task. Store each task as rows in a table and select dates and subjects for the calendar view and all the values of one task when editing. VS has some pretty good tools to create such an application in a few minutes (for an experienced user)

Handling files is always a mess when several persons need to edit the data at the same time.

Answer 3

Firstly this is a persistence problem and should be dome using well known patterns. You could use a database and repository pattern to solve this. Nosql database are also an option ,as thy are easy to setup and lacks the overheads associated with SQL dbs.

But if flat files is your option then holding all data in memory has the flaw of when an exception occurs or the program shut you loose all you data. Persistence is necessary using create read update ans delete CRUD cycles. This results in persisting in small chunks as you go and you only loose a small amount of data if you crash.