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

Что требуется
Требуется электронный справочник или база датчиков и измерительных систем с функциями поиска, редактирования и удобного вывода максимально полной информации о датчике или измерительной системе.
Информация о каждом датчике в справочнике может быть дополнена связанными документами: изображение датчика, чертеж датчика, схема подключения, методика градуировки, сертификат и т.п.
Зачем требуется
Подробные спецификации датчиков необходимы для принятия конструкторских решений, подбора датчиков удовлетворяющих условиям технического задания разрабатываемой системы измерений. Представление данных в электронном виде позволит повысить актуальность данных, ускорить поиск информации и упростить обмен данными при согласовании и приемке изделий.
Особенности
  • Большинство спецификаций датчиков и измерительных систем сейчас хранится на бумажных носителях в справочниках и каталогах производителей.
  • Конструкторская документация создается в CAD средствах.
  • Система электронного архива предприятия находится на этапе внедрения.
  • Система управления предприятием построена на базе СУБД Oracle, но не охватывает все производственные процессы.
  • Инициатива создания описанного справочника идет снизу (от отдела разрабатывающего системы измерений), реализацию предполагается передать паре программистов C# (сотрудников этого отдела - кто и задает этот вопрос).
  • В случае успешного внедрения системы предметная область будет расширяться (например, электротехнические компоненты, разъемы и собственные изделия - согласующие устройства и системы измерений)
Личные соображения
Система, объединяющая информацию о разных типах датчиков, разных производителей (в т.ч. и зарубежных) должна иметь гибкую структуру данных.
Хочется решить задачу максимально просто "без наворотов", что бы в будущем справочник можно было интегрировать в систему управления предприятием, когда там наведут порядок или внедрят ту же PDM (очень далекая перспектива).
Вопрос
Уважаемые Знатоки, посоветуйте, пожалуйста, возможные средства реализации такого справочника, расскажите о личном опыте решения подобных задач, и потенциальных проблемах.
  • Вопрос задан
  • 687 просмотров
Решения вопроса 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
Я мастер на все руки, я козлик Элек Мэк :-)
Ну, даже не знаю что здесь посоветовать... Может быть как вариант 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
Ответ написан
Ваш ответ на вопрос

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

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