Alex XYZ

>> Реляционная база подходит или стоит посмотреть в сторону 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.

Остальные сущности по бизнеслогике вы описали нормально. Лично я бы в постановке задал бы несколько вопросов непосредственным исполнителям этой бюрократической процедуры, а так вроде все норм.

Знаете, я с вами соглашусь, что хорошую вводную по Elastic трудно найти. Пока сам не переварил доков и не набил шишек многие элементарные понятия оставались для меня неясными. Поэтому вот моя вводная: Elastic можно использовать как NoSQL БД, только надо быть внимательным, т.к. всё-таки его основная задача поиск, а не удовлетворение функций БД. Например, если вы не настроили хранение исходных данных, а только индексацию, то свои данные вы уже не извлечёте из него. НИКОГДА. Только отдельные выражения, удовлетворяющие условиям поиска. Всё, тупик. Так же нельзя повторно индексировать уже загнанные в него данные. Т.е. перед загрузкой данных надо грамотно настроить индексацию, т.к. перестроить индекс, как это делается в реляционной БД невозможно. Нужно придумать новую схему индексации и перезалить данные в Elastic. Именно поэтому основное использование Elastic - как дополнение к существующей БД из которой данные можно перезалить по одному или полностью в Elastic (можно, конечно сделать схему Elastic->Elastic, но тоже есть нюансы).
Ещё пару слов про схему. Это ЛОЖЬ, что в Elastic нет схемы данных. Она как раз есть и ооочень жёсткая. Жёсткая до того, что однажды определив, вы не сможете её поменять. Изначально Elastic оказывает медвежью услугу, разрешая вам дополнять схему по-умолчанию, но когда вы разберётесь с этой темой, то можете обнаружить, что Elastic "понастроил" такого у себя внутри, что остаётся только охреневать и переделывать всё явно, отказавшись от его "услуг" по автоматическому добавлению полей в схему.
Так же в Elastic очень непросто строить сложные запросы на поиск и агрегатные запросы. Совершенно неинтуитивно. Но если освоитесь, то будет вам счастье. )))
Несмотря за такие "страшные" вещи - Elastic классная система и по производительности агрегатных запросов не уступает платной версии MSSQL в поиске в многопроцессорных системах (проверял на одинаковых аппаратных конфигурациях с 16 ядрами). Так что если вам хочется большую скорость в агрегатных запросах и главное - это бесплатность, то берите и осваивайте Elastic. Мощности и возможности у него огромные. Но... нужно потратить приличные усилия на изучение.