Еще раз большое Спасибо Всем респондентам, за советы и аргументы.
Хочу отписаться о результате изучения предложенных тем и советов (извиняюсь что время спустя т.к. был в отъезде).
Тема
NoSQL оказалась очень интересной, и изучение её не прошло даром, но на данном этапе реализации описанного электронного справочника было решено делать
реляционную БД.
Причины:
- От разработки структуры данных все равно не убежишь, будь это таблицы или объекты.
- Решили "распараллелить" разработку справочника и наполнение данными, для ускорения выявления дополнений к структуре данных и сокращения срока реализации.
- Вопрос по поводу конечного средства реализации справочника пока остается открыт, хочется оставить возможность объединить в перспективе с базой предприятия, хотя заказчик в лице отдела пока не видит таких перспектив.
- Импорт данных из БД жесткой структуры в целевую среду (какой бы она не была) будет всегда лаконичнее.
- NoSQL как альтернативное средство всегда поддержит переход от реляции, если же идти в обратном направлении, проблем может быть больше.
- Характерные для NoSQL задачи гибкого поиска и масштабирования пока не выявлены в требованиях к справочнику. Однако внедрение в качестве поисковой системы очень даже интересно на перспективу.
Для скорейшего перехода от реализации БД к наполнению данными выбрали простейшее СУБД Access (да не оч. серьезно, но простота в разработке, знакомость пользователям и наличие пакета Office берут свое). Для снижения объемов "двойной работы" в будущем при переходе к "конечному" средству реализации разработку вели с использованием средства автоматизации проектирования ERwin, что позволит в дальнейшем передать готовую схему данных в целевую среду, а Access использовать как источник данных для одноразового импорта.
Логическая схема данных в ERwin:
Схема данных в среде Microsoft Access после добавления таблиц под перечисляемые типы данных:
