1

I've got a git repository having such arborescence :

  • app
  • data
  • README.md

Files inside "data" are usually JSON files that are updated after some users actions on front side. When a file has been updated, I would like to commit & push it to have an history.

Is it a good idea to use git as a "database", in the same git repo than source code ? Maybe it would be cleaner to create a dedicated repo just for the data ?

I thought about this solution because my JSON files are small and not updated frequently. I think I would spend more time creating a database with MariaDB than just saving my data in a file. Also I need a historic, and I must have that files on 2 places (in case the main server crashes). The JSON files are independent and do not share the same data structure.

Improve this question
6
  • 2
    As asked 'no'. Why store data in git at all, what's the reason to want to do that (it's possible that's fine, there isn't enough context in the question to say though)? Commented Apr 12, 2021 at 13:47
  • Because I need to keep a historic and to have that file on 2 places. (in order to keep it if server crashes like OVH ones ^^ ) Commented Apr 12, 2021 at 13:55
  • 1
    please edit the question to clarify, don't write comments (also, please don't just copy your comment into the question, elaborate more - like how is git your first thought for a recovery plan? Why is the data json at all? Why isn't the app's data in a db? etc.). Commented Apr 12, 2021 at 15:12
  • @AD7six, ok I added somethings Commented Apr 13, 2021 at 6:51
  • 2
    I think I would spend more time building a database That's an interesting comment :). E.g. I've been writing software for 25 years in varied fields and never once built, or thought to build, a database - why are the only two choices 'use json files' or 'build a database'... where is use a preexisting database? sqlite sounds like it would be one suitable candidate. You can do what you ask (do not store data in the same repo as code, use two repos), but it's abnormal - and the info provided for wanting to do it that way don't justify the approach. Good luck :) Commented Apr 13, 2021 at 8:45

1 Answer 1

Reset to default
1

To answer your question : If you want to go with this method. i think it would be better to create a repo just for the 'data'. To reduce risk of conflicts when you are working on it while in production.

Then i don't think it is the best method:

There are some cons using this method:

  • If you plan to have a lot of commit by second, it is not the fastest way to do so, since git need to write the files to disk before doing the commit. If you work with many sub folder instead, you could maximize this limited commit by second. The reason is that when you create a commit, you have to copy the tree, make the change and then save the tree.

  • It can be problematic if users are allowed to read and write at the same time as it can cause conflicts. This can be fix by locking write/read in certain situation.

I read this article ( https://www.kenneth-truyers.net/2016/10/13/git-nosql-database/ ), wich show how to use git as a NoSql database, showing a lot of pros and cons and explain a lot of things about it. There is a lot of cons, and a lot of solution for those cons. But it seems out of the way to fix those, why not using a technology that do not require all these work around in the first place.

although i never used git that way, the fact that you need a lot of work around and setup for this, i think it is best to use a database rather than using git as a database. And for tracking your data, you could use a table, store the action, the information of the object, the date and time and the user who modified it, and then you have an history

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

For tracking data, I totally agree with you. But building a specific table needs more work than just commiting a file. Anyway I do understand that it's probably the best way.
It may take some times building a database, depending on your knowledge and the technology you use, but it should not take that much time, and the time you put making that database, you may be saving it later not resolving conflict. You can also create a task that take a backup so you don't loose your data if something happen. and as far as i know, SQL query is as quick as a commit (even quicker maybe) if you just do some basic CRUD operations. In the end, we all have our method. Use what is more comfortable to you.
I think you're right. Thanks for your advice and time ;)

Your Answer

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.