Какое средство реализации Электронного Справочника Технической Документации посоветуете?

Что требуется
Требуется электронный справочник или база датчиков и измерительных систем с функциями поиска, редактирования и удобного вывода максимально полной информации о датчике или измерительной системе.
Информация о каждом датчике в справочнике может быть дополнена связанными документами: изображение датчика, чертеж датчика, схема подключения, методика градуировки, сертификат и т.п.
Зачем требуется
Подробные спецификации датчиков необходимы для принятия конструкторских решений, подбора датчиков удовлетворяющих условиям технического задания разрабатываемой системы измерений. Представление данных в электронном виде позволит повысить актуальность данных, ускорить поиск информации и упростить обмен данными при согласовании и приемке изделий.
Особенности
  • Большинство спецификаций датчиков и измерительных систем сейчас хранится на бумажных носителях в справочниках и каталогах производителей.
  • Конструкторская документация создается в CAD средствах.
  • Система электронного архива предприятия находится на этапе внедрения.
  • Система управления предприятием построена на базе СУБД Oracle, но не охватывает все производственные процессы.
  • Инициатива создания описанного справочника идет снизу (от отдела разрабатывающего системы измерений), реализацию предполагается передать паре программистов C# (сотрудников этого отдела - кто и задает этот вопрос).
  • В случае успешного внедрения системы предметная область будет расширяться (например, электротехнические компоненты, разъемы и собственные изделия - согласующие устройства и системы измерений)
Личные соображения
Система, объединяющая информацию о разных типах датчиков, разных производителей (в т.ч. и зарубежных) должна иметь гибкую структуру данных.
Хочется решить задачу максимально просто "без наворотов", что бы в будущем справочник можно было интегрировать в систему управления предприятием, когда там наведут порядок или внедрят ту же PDM (очень далекая перспектива).
Вопрос
Уважаемые Знатоки, посоветуйте, пожалуйста, возможные средства реализации такого справочника, расскажите о личном опыте решения подобных задач, и потенциальных проблемах.
  • Вопрос задан
  • 709 просмотров
Решения вопроса 1
@aleksei4 Автор вопроса
Еще раз большое Спасибо Всем респондентам, за советы и аргументы.
Хочу отписаться о результате изучения предложенных тем и советов (извиняюсь что время спустя т.к. был в отъезде).
Тема NoSQL оказалась очень интересной, и изучение её не прошло даром, но на данном этапе реализации описанного электронного справочника было решено делать реляционную БД.
Причины:
  1. От разработки структуры данных все равно не убежишь, будь это таблицы или объекты.
  2. Решили "распараллелить" разработку справочника и наполнение данными, для ускорения выявления дополнений к структуре данных и сокращения срока реализации.
  3. Вопрос по поводу конечного средства реализации справочника пока остается открыт, хочется оставить возможность объединить в перспективе с базой предприятия, хотя заказчик в лице отдела пока не видит таких перспектив.
  4. Импорт данных из БД жесткой структуры в целевую среду (какой бы она не была) будет всегда лаконичнее.
  5. NoSQL как альтернативное средство всегда поддержит переход от реляции, если же идти в обратном направлении, проблем может быть больше.
  6. Характерные для NoSQL задачи гибкого поиска и масштабирования пока не выявлены в требованиях к справочнику. Однако внедрение в качестве поисковой системы очень даже интересно на перспективу.


Для скорейшего перехода от реализации БД к наполнению данными выбрали простейшее СУБД Access (да не оч. серьезно, но простота в разработке, знакомость пользователям и наличие пакета Office берут свое). Для снижения объемов "двойной работы" в будущем при переходе к "конечному" средству реализации разработку вели с использованием средства автоматизации проектирования ERwin, что позволит в дальнейшем передать готовую схему данных в целевую среду, а Access использовать как источник данных для одноразового импорта.

Логическая схема данных в ERwin:
dc47ea1efd4142c29f61ab4d8d254095.JPG

Схема данных в среде Microsoft Access после добавления таблиц под перечисляемые типы данных:2f31d37dbdb0426cb72270dd5c53acc9.JPG
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
leahch
@leahch
3Д специалист. Долго, Дорого, Дерьмово.
Ну, даже не знаю что здесь посоветовать... Может быть как вариант elasticsearch?! Поиск есть, документы хранить умеет, nosql опять же, разные типы данных тоже можно добавлять... вот попробуйте - habrahabr.ru/company/percolator/blog/222765

ЗЫ. С эластиксерч не работал еще, но в свое время, лет 10 назад очень плотно работал с люсиной (которая в его основе), там мы как раз и хранили в ней документы именно для поиска. От люсины впечатления очень положительные!
ЗЗЫ. Прямо по статье, так и делали (с люсиной).
Elasticsearch обычно используется в качестве дополнения к другой, основной, базе данных — с сильным акцентом на ограничения, корректность и надежность, а также транзакционно обновляемой. Соответственно, данные сначала записываются на основную базу, а затем асинхронно — в Elasticsearch
А теперь, по ходу, можно и в нем держать....

PPPS.
habrahabr.ru/post/122531 - вот для начала работы.

PPPPS. И не пугайтесь явы, с ним и на C# работать можно.
Ответ написан
des1roer
@des1roer
ученье - свет, а неученье - приятный полумрак
А в чем хитрость?
Postgres + Yii
в базе храним данные, с помощью yii (по вкусу) выводите на свой локальный сайт. при чем тут C# ? на asp.net есть желание такое делать?
UPD
а у вас что связь many-to-many запретили?
q6WqI3N.png
и по тому же хабру nosql больше хают, чем превозносят

habrahabr.ru/post/231213
habrahabr.ru/post/253075
можете ознакомиться.

и да - у меня сейчас отлично работает и поиск и разное количество столбцов в зависимости от шаблона.

и еще - сколько данных хотите хранить?

ну как, нашли серебрянную пулю?
я вот тут свои мысли изложил des1roer.blogspot.com/2015/06/yii.html
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы