beevasya
@beevasya
программист C++/C#

Как лучше реализовать систему складского учета с динамическими свойствами?

Есть проект, разработка системы для бытового многопользовательского складского учета. У каждого пользователя свой склад.
Объекты складского учета разнообразные. Предполагается что поставщиком будет производиться базовая конфигурация системы под нужды потребителя, а в дальнейшем структура и состав может меняться в рамках одной предметной области. При этом вся настройка должна осуществляться через некоторую админку.
Основная цель - минимизировать время на настройку системы под разные предметные области без спец. знаний в области программирования и БД, по сути дела некоторая nocode система складского учета на web-основе, многопользовательская.
Вероятный пример - учет домашних заготовок. Конфигурируем изначально под хранение закаток (наименование, состав, дата закатки, срок хранения). Пользователи регистрируются и начинают вести свой учет, но со временем по обратной связи видим, что не хватает поля для места расположения в погребе, соответственно добавляем без вмешательства в код. Та же система, но теперь отдельные сервис для хранения инструментов, опять же новые сущности, новые поля и т.д. Без программирования, настраиваем сущности, поля и запускаем новый сервис.
Вопрос. Как лучше реализовать работу с БД при такой функциональности?
Сейчас есть несколько вариантов:
1. Классика реляционной СУБД. Создаем сущность "Объект хранения", создаем сущность "Свойства объекта", определяем связи и т.д.
2. Реализация некоторого фреймворка для работы с данными (тоже на основе реляционной СУБД), который при редактировании сущностей в админке, изменяет структуру БД, такую реализацию видел в EspoCrm
3. Решение на основе MongoBD (тут пока только теоретические знания)
Возможно есть какие-то другие варианты? Возможно есть какие-то готовые подобные решения?
Сейчас интересуют мнения, опыт, плюсы/минусы различных реализаций...
Заранее спасибо

PS Планируется реализовывать на php или python, фронтенд в виде SPA
  • Вопрос задан
  • 118 просмотров
Пригласить эксперта
Ответы на вопрос 2
@Everything_is_bad
Есть EAV у которого начиная с определенного количества товаров, возникает проблема со скоростью. Обычно его берут как основу, но делают компромиссный вариант, например денормализация базы с использованием jsonb в postgresql
Ответ написан
Комментировать
@alexalexes
Посмотрите реализацию конструктора супер-типа, например, в CMS Modx - Migx.
Из коробки он делает именно то, что вы хотите. Администратор создает новый тип, который может включать несколько свойств, а может еще быть свойства-списки, причем, тоже кастомного типа.
Единственная проблема Migx - нужно учиться понимать концепцию этого конструктора и определенное время на обучение созданию структур. Он не имеет интуитивно понятный интерфейс, вы тоже не сделаете интерфейс лучше.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы