Can different entities of objects be combined in one table?

Question

MySQL

Hello.
I work at a construction company, one of the types of duties is the preparation of responses to incoming documentation.
I have to work constantly with Excel and Word and a lot of photos. Very inconvenient and labor intensive. I decided to write a database, a server and a browser application. Familiar with SQL queries and Nodejs.
The scheme of work is as follows:

1. Letters from the City Administration, physical. persons - citizens of the city, legal. persons - private firms, enterprises, city departments are registered as incoming with their unique numbers
   
2. Whether the answer was received or the work specified in the letter was performed
   
3. An answer is being prepared (there may be many corrections, different versions )
   
4. Preparing the final outgoing letter
   

How to organize a database? Is a relational database suitable or is it worth looking towards NoSQL?
When designing the database, I singled out four entities (CITIZENS, ADMINISTRATION, DEPARTMENT, ENTERPRISE), each with unique attributes ({name, phone, binding to the house, address of registration}, {district, position, administrative name} many inconsistencies), which refer to the JOURNAL INCOMING LETTERS. The main link in the journal is the ADDRESS OF THE HOUSE and THE NUMBER OF THE LETTER. Also, every day there is a task to check what information was given earlier in the letter. To do this, I also built a link table (NUMBER OF THE PARENT LETTER and NUMBER OF THE DESCENDANT OF THE LETTER). But the problem is how to understand which entity to select by the number of the letter and select data on the applicant. Or is this issue resolved at the application level?
I also wanted to ask how to solve the issue with the versioning of the outgoing letter.
The application must work with many users.

Answer 1

>> Is a relational database suitable or is it worth looking towards NoSQL?
It is correct to store the primary data in the relational database, and write the changes that employees make (versioning) into a separate JSON entity and add them to a separate table. The fact is that business logic may require the ability to work with transactions, and in NoSQL they are supported only at the document level (ElasticSearch, Mongo). If during operation you need to roll back changes in several entities, then NoSQL will not provide you with this.
There is an option to cross NoSQL and relational databases - use JSON in MySQL. But here there will be another problem - checking the schema of the data being written. Non-trivial task for MySQL. In general, NoSQL is still damp today, and you need to work on it to use it in projects. In Mongo, the schema seems to be there, in ElasticSearch it’s generally tough on the schema (since you ask a question, you definitely haven’t come across it and I assure you that you will spend no less time studying the schema in Elastic than on the project itself)
Yesterday I just answered a similar question with versioning in MySQL: How to do versioning like on a wiki?
As for versioning, there is one more thing - how to protect entities from being overwritten by another user? Based solely on my subjective opinion, I make an incremented field (say, version) for each entity (a group of values ​​​​that I take as an entity), the value of which I give when selecting from the database. When saving an entity, the client is required to provide this index. If the index has not changed, then the write is allowed. As soon as the entity is written, I increment this field, and if another person also tries to overwrite the data with the old value of the version field, the program will not allow him to do this (this is a very primitive blocking method, very vaguely reminiscent of git. Hashes are used there, well, I simplified everything to disgrace) Checking the value of the version field is done in the trigger, it also cancels the write process if the versions do not match (which just cannot be done in pure NoSQL). It would be possible to do a read lock as in 1C, but for programs not at the 1c level, we have a bunch of hemorrhoids during implementation.
As for Excel and Word, read the description of the OOXML format and see the libraries for working with office formats. For Node I don't know, but for Java and C# there are very powerful ones if you don't want to deal with OOXML.
The rest of the entities in terms of business logic you described normally. Personally, in the production, I would ask a few questions to the direct executors of this bureaucratic procedure, but everything seems to be normal.

Answer 2

Can buy a ready-made document management system.