It may not be clear so I'll develop the idea:
The point is to develop a web interface to write down notes (and anything you like), and track its evolution. My question is then: how can I store such information such that I can also keep track of modification history?
On the relational database world it would ideally look like:
| docId | authId | content | <meta> |
| docId | editDate | <data> |
The question is about what to store as the
documentHist.<data>. Should I store here all the revisions (easy but huge replication)? Or should I store only differences? (smarter, but no see how I could do this (without implementing a kind of versioning system myself).
That's why I previously mentionned Git, and even more Github which precisely do it: you can edit files and commit. We could then use here Git "under the hood" for our versioning. I'm just not sure how difficult this would be. (Select/Update &co looks easier to me that handling files and git command from web server, I'm maybe wrong)
Thanks for any comment, clue or idea. I maybe have minsunderstanding or misconception, do not hesitate to point it out. (same for language mistake, I'm not EN native as you may have noticed)
History isn't backup: My point isn't to create database backups but instead to be able to query/work with edit history (e.g. tell the user when/what was the last modification, when was this line added etc...
Documents: By document I do not (necessarily) talk about file on a file system. It could just be record in a database (we could imagine 1 table for the current content of "document" and 1 for its history)
Volume & Goals: I aim to develop such a system for personnal need, but with a scalable design. I would otherwise just use Git. The point is to give a wbe interface to write down notes and keep track of evolutions (among other features)