Могут ли разные сущности объектов объединять в одной таблице?

Question

[Anthony]

Здравствуйте.
Работаю на строительном предприятии, один из видов обязанностей это подготовка ответов на входящую документацию.
Работать приходится постоянно с Excel и Word и большим количеством фотографий. Очень неудобно и трудозатратно. Решил написать базу данных, сервер и браузерное приложение. Знаком с SQL запросами и Nodejs.

Схема работы такова:

1. Письма от Администрации города, физ. лица - граждани города, юрид. лица - частные фирмы , предприятия, Департаменты города оформляются как входящие со своими уникальными номерами
   
2. Проверяются был ли ответ или выполнялись работы указанные в письме
   
3. Готовится ответ (много исправлений могут быть, разные версии)
   
4. Готовится окончательный исходящие письмо
   

Как организовать базу данных? Реляционная база подходит или стоит посмотреть в сторону NoSQL?

При проектировании базы данных выделил четыре сущности (ГРАЖДАНИ, АДМИНИСТРАЦИЯ, ДЕПАРТАМЕНТ, ПРЕДПРИЯТИЕ) каждый имеет уникальные атрибуты ({имя, телефон, привязка к дому, адрес прописки}, {район, должность, административное название} много несовпадений), которые ссылаются на ЖУРНАЛ ВХОДЯЩИХ ПИСЕМ. Основная связь в журнале это АДРЕС ДОМА и НОМЕР ПИСЬМА. Также ежедневно стоит задача проверить какую информацию давали раньше по письму. Для этого построил еще таблицу связей (НОМЕР РОДИТЕЛЬСКОГО ПИСЬМА и НОМЕР ПОТОМКА ПИСЬМА). Но проблема как понять какую сущность выбрать по номеру письма и отобрать данные по заявителю. Или этот вопрос решается на уровне приложения?

Также хотел спросить как решать вопрос с Версионностью исходящего письма.
Приложение должно работать с многими пользователями.

Answer 1

[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.

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

Comments

[Александр Шелеметьев]

Дополню. Если есть возможность, то предлагаю посмотреть в сторону PostgreSQL с JSONB полями для хранения документов. Ключевые реквизиты документов триггером, например при записи, можно переносить в реляционные поля. Тут и проверку схемы можно прикрутить. Для ускорения поиска по неключевым реквизитам документа можно использовать индексы на JSONB.

Answer 2

[Константин Цветков]

Может купить готовую систему документооборота.