Блог

Я надеюсь, что кто-нибудь может предложить предложение / решение проблемы, с которой я в настоящее время сталкиваюсь. Я пытаюсь создать административную панель для платформы здравоохранения. Панель должна быть доступна главному администратору, а также администратору hcp (поставщику медицинских услуг). Функции на панели администратора будут доступны в зависимости от роли пользователя: главный администратор-бог, поэтому у них будут функции глобального администратора, такие как операции CRUD (создание/редактирование/удаление), другие администраторы и т. Д., А у администратора hcp будут только определенные функции, такие как управление только пользователями, которые принадлежат к их hcp (например, врачи, которые там работают), управление календарем / встречами и отчетами. Стек, который я использую, — это nodejs и postgresql сзади и реагирует/ спереди. Каков наилучший подход к настройке отношений между таблицами в postgresql? Или лучше использовать NoSQL, как MongoDB?

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

1. Соберите требования, особенно касающиеся безопасности/соответствия требованиям. Должна ли система сохранять конфиденциальность данных? Нужно ли пользователям также входить в систему, используя специальные имена пользователей/пароли на стороне БД? (Это было предусмотрено для конфиденциальных данных в некоторых законодательных актах до GDPR, так что проверьте!) Нужна ли вам безопасность на уровне строк, чтобы запросы не могли видеть строки «других пользователей»?
2. Оцените свою модель данных, включая не только сохраненные записи, но и их динамику. Нужно ли удалять записи вместе и изменять их вместе? Является ли удаление данных проблемой (это может быть для медицинских учреждений)? Наконец, у вас уже есть строго реляционная модель? Если да, то было бы неудобно и контрпродуктивно применять NoSQL, нереляционную базу данных, к данным и процессам, которые явно извлекают выгоду из отношений и семантики ACID.
3. Рассмотрим доступные архитектурные стили. Будет ли приложение формировать классическую 3-уровневую (интерфейсную, серверную, БД) структуру или будет какая-то форма промежуточного программного обеспечения, например API доступа к данным или прокси-сервер? Существует ли существующее промежуточное программное обеспечение, с которым вам необходимо интегрироваться?
4. Наконец, взгляните на примеры использования и решите, как подходит система разрешений. В разрешениях вашей основной заботой будет авторизация, т. е. разрешено ли данному субъекту (пользователю) выполнять операцию. Это никогда не происходит в вакууме, поэтому вы должны учитывать следующие контексты:
   • Извлечение данных — как отфильтровать доступные данные, чтобы ограничить видимость. Это часто сложнее (или, по крайней мере, более ресурсоемко), чем защита разрешений на запись! Как правило, это реализовано в качестве дополнительных условий WHERE, представлений SQL или безопасности на уровне строк.
   • Операции записи (создание/обновление/удаление, вызов RPC) — как убедиться, что субъект уполномочен выполнять данную операцию, и что делать, если они не выполняются (в том числе, в каком состоянии будет находиться система, если что-то не получится в середине пути? — проще с SQL, потому что у вас есть транзакции).
   • Внешние пользователи, такие как API, настольные приложения, терминалы, медицинские устройства, возможно, даже принтеры? Нужно ли им подключаться к системе? Если да, то смогут ли они выполнять свои задачи в рамках установленной системы разрешений или необходима другая параллельная система (например, маркеры API на основе возможностей)?

Я знаю, что это многое стоит обдумать, но давайте посмотрим правде в глаза — разработать любую функционирующую программную систему сложно. Тот, который отвечает потребностям чувствительной области бизнеса, такой как здравоохранение? Вдвойне.

Перечислив все вышесказанное, всегда следует сделать оговорку: StackOverflow никогда не будет жизнеспособной заменой реальному моделированию предметной области, поэтому эту часть вы и ваша команда разработчиков должны в значительной степени решать самостоятельно (или передать на аутсорсинг!).