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

Question

[aleksei4]

Что требуется
Требуется электронный справочник или база датчиков и измерительных систем с функциями поиска, редактирования и удобного вывода максимально полной информации о датчике или измерительной системе.
Информация о каждом датчике в справочнике может быть дополнена связанными документами: изображение датчика, чертеж датчика, схема подключения, методика градуировки, сертификат и т.п.
Зачем требуется
Подробные спецификации датчиков необходимы для принятия конструкторских решений, подбора датчиков удовлетворяющих условиям технического задания разрабатываемой системы измерений. Представление данных в электронном виде позволит повысить актуальность данных, ускорить поиск информации и упростить обмен данными при согласовании и приемке изделий.
Особенности

• Большинство спецификаций датчиков и измерительных систем сейчас хранится на бумажных носителях в справочниках и каталогах производителей.
  
• Конструкторская документация создается в CAD средствах.
  
• Система электронного архива предприятия находится на этапе внедрения.
  
• Система управления предприятием построена на базе СУБД Oracle, но не охватывает все производственные процессы.
  
• Инициатива создания описанного справочника идет снизу (от отдела разрабатывающего системы измерений), реализацию предполагается передать паре программистов C# (сотрудников этого отдела - кто и задает этот вопрос).
  
• В случае успешного внедрения системы предметная область будет расширяться (например, электротехнические компоненты, разъемы и собственные изделия - согласующие устройства и системы измерений)
  

Личные соображения
Система, объединяющая информацию о разных типах датчиков, разных производителей (в т.ч. и зарубежных) должна иметь гибкую структуру данных.
Хочется решить задачу максимально просто "без наворотов", что бы в будущем справочник можно было интегрировать в систему управления предприятием, когда там наведут порядок или внедрят ту же PDM (очень далекая перспектива).
Вопрос
Уважаемые Знатоки, посоветуйте, пожалуйста, возможные средства реализации такого справочника, расскажите о личном опыте решения подобных задач, и потенциальных проблемах.

Answer 1

[aleksei4]

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

1. От разработки структуры данных все равно не убежишь, будь это таблицы или объекты.
   
2. Решили "распараллелить" разработку справочника и наполнение данными, для ускорения выявления дополнений к структуре данных и сокращения срока реализации.
   
3. Вопрос по поводу конечного средства реализации справочника пока остается открыт, хочется оставить возможность объединить в перспективе с базой предприятия, хотя заказчик в лице отдела пока не видит таких перспектив.
   
4. Импорт данных из БД жесткой структуры в целевую среду (какой бы она не была) будет всегда лаконичнее.
   
5. NoSQL как альтернативное средство всегда поддержит переход от реляции, если же идти в обратном направлении, проблем может быть больше.
   
6. Характерные для NoSQL задачи гибкого поиска и масштабирования пока не выявлены в требованиях к справочнику. Однако внедрение в качестве поисковой системы очень даже интересно на перспективу.
   

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

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


Схема данных в среде Microsoft Access после добавления таблиц под перечисляемые типы данных:

Comments

[des1roer]

эт конечно прекрасно что вы схемы рисовать умеете. в mysql workbench это тоже можно делать. а при чем тут знакомство пользователям? из первоначального вопроса вроде как следовало что вы делаете распределенную систему. и тут веб+постгрес\мускул напрашивался сам собой. и даже в плане лицензии - под это дело же нужно отводить виндовый сервак? аццес вообще как-то в проде не оч представляю. еще б мс скл все не шло

Answer 2

[Алексей Черемисин]

Ну, даже не знаю что здесь посоветовать... Может быть как вариант elasticsearch?! Поиск есть, документы хранить умеет, nosql опять же, разные типы данных тоже можно добавлять... вот попробуйте - habrahabr.ru/company/percolator/blog/222765

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

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

PPPPS. И не пугайтесь явы, с ним и на C# работать можно.

Comments

[des1roer]

евангелист ElasticSearch ? nosql же готовить надо уметь. а ТС вряд ли из google

[aleksei4]

Спасибо, обещаем не пугаться =)

[Алексей Черемисин]

des1roer: на мой взгляд, nosql готовится гораздо легче sql, и уж несравнимо легче модифицируется.

[des1roer]

Алексей Черемисин: каждый сам себе роет яму. или каждый кузнец своего счастья. тут на выбор тс. я как не работал с nosql так и думаю придерживаться того же курса.

[Алексей Черемисин]

des1roer: Извиняюсь, наверное меня не совсем правильно поняли. Обычно "поиск" применяют так: есть база данных, реляционная или нет - без разницы, пусть будет реляционная. Рядом с ней стоит "поиск", как только что-то изменяется в связанных таблицах базы, асинхронно обновляются данные в "поиске". Нетипичные и полнотекстовые запросы делаются через "поиск", а вся остальная работа ведется в базе данных.
В этом случае получаем очень много преимуществ, фактически недоOLAP к нашим данным. Обновлять данные в "поиске" можно разными путями, как на каждый чих, так, например, и раз в полчаса по изменениям.
Еще раз, я не говорю "выкиньте свой SQL", я говорю "попробуйте проиндексировать свои данные не в SQL"! И заметьте, я не наставиваю, где эти данные должны храниться, в файлах, логах, блобах или таблицах...

[Алексей Черемисин]

Из поиска мы получаем набор PK и/или FK, поля соответствия, релевантность и т.д. Если данных для отображения достаточно и не нужно лезть в базу, то их и используем. Если нужно что-то догрузить из базы - догружаем, сверяем, аккумулируем и т.д.

[Алексей Черемисин]

Поисковики можно рассматривать, как метаиндекс в уже существующим данным, и это хорошо.

[des1roer]

Алексей Черемисин: ну это что то вроде представлений из sql? я вот ни разу не "готовил" Nosql. так что мнение возможно однобокое. но вот хранить кэш где-то еще отдельно от базы - это можно хоть где

[Алексей Черемисин]

des1roer: Есть случаи, и их много, когда все данные помещаются в кеш, ну и зачем тогда держать две базы? И есть случаи, когда и сам кеш не нужен, ну и нафиг его.
PS. Прочитал по вашим ссылкам статьи из хабра, это как раз случаи неправильного выбора кувалды. Тем более они и сами пишут, что данные - реляционные, ну и зачем, собственно их понесло в монгу? С другой стороны у нас и монга и реляционка и где-то просто файлы конфигурации. Вот про файлы конфигурации у меня может быть рассказ "как я ушел с MySQL на файлы json"!

[Алексей Черемисин]

О! там в статьях комменты бывают интересные - habrahabr.ru/post/253075/#comment_8330149

[Алексей Черемисин]

А вот как раз про эластик - habrahabr.ru/post/253075/#comment_8330255

Answer 3

[des1roer]

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

и по тому же хабру nosql больше хают, чем превозносят

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

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

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

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

Comments

[Алексей Черемисин]

Э???? А как сделать так, что два датчика разных производителей имеют разный набор характеристик? Как базу делать под это будем? А как потом искать по 10-20 характеристикам сразу и по трем четырем производителям? Тут автор топика правильный вопрос задает! Мы что под каждый датчик свою таблицу строить будем? SQL, оно, немного не того... для данной задачи.

[aleksei4]

Космических объемов не планируется, но с освоением новой аппаратуры, объем данных будет только расти. "Время жизни" модели измерительного датчика на рынке довольно велико, и новые тоже регулярно появляются.
Если говорить только о датчиках - до 3 тыс. основных записей где-то.
Если система будет расширяться по разъемам, компонентам и прочему, добавится ещё столько же.

[des1roer]

aleksei4: это вообще копейки по меркам современных бд. можете хоть sqlite под это использовать. к чему вам nosql?

[Алексей Черемисин]

des1roer: Не, правильный поиск это хорошо. Например у меня есть датчик с полем HWANALOG="SIMATIC", есть датчик с полем HWPROTOCOL="SIMATIC", есть датчик PRODACTION="SIMATIC", так вот по слову SIMATIC я сразу найду все три датчика. В вашем же случае нужно будет отдельно, прямо или косвенно опрашивать эти поля.
Да и я знаю про провязочные таблицы, но уж поверьте, это совсем не легко, осуществлять по ним поиск.
И да, ничуть не умаляю SQL, более того, в своем ответе написал, что база данных как бы желательна (но не необходима). Sql/nosql, неважно. Но положив данные из базы (например) в правильный поисковик, уверяю, получите гораздо больше в плане поиска, а здесь как раз он и нужен.

[des1roer]

Алексей Черемисин: если у вас только поиск и никаких изменений - Nosql ваш путь. а вот когда столкнетесь с реляцией и прочими связностями, проклянете все и напишите такую же статью как я выше приводил )))