3

I am developing a small application as a hobbyist. This application will track costs (eg. purchases and sales, ...) for a single person company.

Only string, date, double, integer, and decimal types are stored. References to files will be path.

I want to store this data somewhere structured and my SQL knowledge is below zero. So I am thinking why not use a .XML file? Is this a considered a bad practice?

If I continue using the XML save system I could still port the data later to real relational database if required ( I think? ).

Or would it be wise to hit the books and catch up on SQL?

1
  • Welcome Mech_Engineer. I believe you got a down vote because this may be a better question for a forum. That being said, I'll try to give you somethings to think about.
    – Jeff
    Commented Sep 13, 2018 at 14:07

3 Answers 3

8

Storing data in textual files such as XML or JSON is perfectly fine, but has a couple of restrictions. Every time you need to read some data you first have to load the whole file, and for any change you need to write the whole file back to disk. Many document formats such as .docx actually use this approach (well, a ZIP archive of XML files to be precise).

But because you always have to read and write all the data, this only works fine for small amounts of data, maybe up to a few MB. That might be more than enough for your use case, but larger scenarios benefit from a real database that can do incremental updates. You don't have to deploy a separate database server. For a single-user scenario, embedded database engines like SQLite can be used instead.

To keep the flexibility to switch between different storage mechanisms, consider using an architecture like the repository pattern or a data access layer to separate your main code from any code that interacts directly with the storage.

2

What are your goals?

  • creating a small application just for yourself, for real usage in your one-person company, with as little effort as possible? Then using anything larger than an XML file would probably be overengineering.

  • do this for learning purposes, to get experience in writing bigger applications? Then use a database, learning SQL is definitely something every professional application programmer could benefit from.

There is no "good practice" or "bad practice" in a vacuum - only solutions which fit well or not so well to given requirements.

I could still port the data later to real relational database if required ( I think? ).

Yes, you could, but there are different ways to achieve this, with different costs. If, for example, you still are happy with a single-user solution, the effort might be low, since you can implement loading and saving the full dataset at once from the db, just as you would load all data from an XML file at once. If, however, you want to achieve real multi-user functionality, transactional behaviour, a nifty collision mechanism in case of parallel edits, then the change might cause a full redesign up to the GUI, the portions of data which are displayed/editable at once, and its error handling.

-2

There are a few things to consider before I could give a specific answer to this question, but as a general rule of thumb, I'd say, if you are storing data, it should go into a database. That being said, I know how difficult it can be to try to learn 123124151233 new things at one time, so if you want to store it in an xml file, and you think you can do that, go for it.

Here are a few things for you to consider. What type of app are you writing? If it's a RESTful web app, maybe json would be a better fit. If you are thinking of moving to a relational db later, maybe go with a csv file. Another option (if you want to learn all the new things at once), maybe go with a nosql db like mongo.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.