>> Реляционная база подходит или стоит посмотреть в сторону NoSQL?
Хранить первичные данные в реляционной базе правильно, а изменения, которые делают сотрудники (версионность) записывать в отдельную JSON-сущность и складывать в отдельную таблицу. Дело в том, что бизнеслогика может требовать возможности работы с транзакциями, а в NoSQL они поддерживаются только на уровне документа (ElasticSearch, Mongo). Если во время работы вам потребуется откатить изменения в нескольких сущностях, то NoSQL вам этого не обеспечат.
Есть вариант скрестить NoSQL и реляционные базы - использовать JSON в MySQL. Но тут будет другая проблема - проверка схемы записываемых данных. Нетривиальная задача для MySQL. В общем, NoSQL на сегодняшний день ещё сыроват и для применения в проектах над ним надо попотеть. В Mongo схема вроде как есть, в ElasticSearch вообще жесткач по схеме (раз вы задаёте вопрос, то точно с ним не сталкивались и уверяю, что на изучение схемы в Elastic вы потратите время не меньше, чем на сам проект)
Вчера как раз отвечал на похожий вопрос с версионностью в MySQL:
Как сделать версионность как на вики?
Что касается версионности, то тут есть ещё один момент - как защитить сущности от перезаписи другим пользователем? Основываясь исключительно на своём субъективном мнении я делаю инкрементируемое поле (скажем, version) для каждой сущности (группе значений, которых я принимаю за сущность), значение которого я отдаю при select-е из базы. При сохранении сущности клиент обязан предоставить этот индекс. Если индекс не менялся, то запись разрешена. Как только происходит запись сущности, то я инкрементирую это поле и если другой человек тоже попытается перезаписать данные со старым значением поля version, то программа ему не позволит это сделать (это очень примитивный способ блокировки, очень отдаленно напоминающий git. Там используются хеши, ну а я все упростил до безобразия) Проверка значения поля version делается в триггере, он же и отменяет процесс записи, если версии не совпадают (чего как раз нельзя сделать в чистой NoSQL). Можно было бы сделать как в 1С блокировку чтения, но для программ не уровня 1с имеем кучу геморроя при реализации.
Что касается Excel и Word, то читайте описание формата OOXML и смотрите библиотеки по работе с офисными форматами. Для Node не знаю, но для Java и C# есть очень мощные, если не хотите разбираться с OOXML.
Остальные сущности по бизнеслогике вы описали нормально. Лично я бы в постановке задал бы несколько вопросов непосредственным исполнителям этой бюрократической процедуры, а так вроде все норм.
