Как лучше реализовать систему складского учета с динамическими свойствами?
Есть проект, разработка системы для бытового многопользовательского складского учета. У каждого пользователя свой склад.
Объекты складского учета разнообразные. Предполагается что поставщиком будет производиться базовая конфигурация системы под нужды потребителя, а в дальнейшем структура и состав может меняться в рамках одной предметной области. При этом вся настройка должна осуществляться через некоторую админку.
Основная цель - минимизировать время на настройку системы под разные предметные области без спец. знаний в области программирования и БД, по сути дела некоторая nocode система складского учета на web-основе, многопользовательская.
Вероятный пример - учет домашних заготовок. Конфигурируем изначально под хранение закаток (наименование, состав, дата закатки, срок хранения). Пользователи регистрируются и начинают вести свой учет, но со временем по обратной связи видим, что не хватает поля для места расположения в погребе, соответственно добавляем без вмешательства в код. Та же система, но теперь отдельные сервис для хранения инструментов, опять же новые сущности, новые поля и т.д. Без программирования, настраиваем сущности, поля и запускаем новый сервис.
Вопрос. Как лучше реализовать работу с БД при такой функциональности?
Сейчас есть несколько вариантов:
1. Классика реляционной СУБД. Создаем сущность "Объект хранения", создаем сущность "Свойства объекта", определяем связи и т.д.
2. Реализация некоторого фреймворка для работы с данными (тоже на основе реляционной СУБД), который при редактировании сущностей в админке, изменяет структуру БД, такую реализацию видел в EspoCrm
3. Решение на основе MongoBD (тут пока только теоретические знания)
Возможно есть какие-то другие варианты? Возможно есть какие-то готовые подобные решения?
Сейчас интересуют мнения, опыт, плюсы/минусы различных реализаций...
Заранее спасибо
PS Планируется реализовывать на php или python, фронтенд в виде SPA
Гораздо проще и дешевле взять одно из тысяч готовых решений, в которых все уже учтено.
Это не так просто как кажется на первый взгляд создать вменяемый каталог товаров если у них разные параметры, да еще и чтобы быстро работало.
1. про классику вы явно не додумали. ну если только под "сущностями" не имеется в виду создание новых таблиц под каждый тип товара.
2. Это вообще непонятно к чему. Фреймворк понадобится для любого варианта, но вопрос-то был про структуру хранения
3. Это вариант, но его придется соединять с остальной базой. Поэтому, очевидное решение, это:
4. Обычная реляционная БД, где свойства товаров хранятся в формате "монги" - т.е. json. Это не такой простой в реализации (вот тут как раз и потребуется фреймворк) но наиболее жизнеспособный вариант
Ипатьев, У 4-го вариант вижу проблему связанную с добавлением дополнительных сущностей,
Например, есть складские позиции, а нужно будет добавить несколько складов, а еще несколько городов или несколько стран. Не обязательно что именно так будет, это я придумал на вскидку, но возможно будут другие связанные сущности, боюсь что json здесь не поможет и придется вмешиваться в структуру БД и дописывать код.
Евгений Решетников, да их миллион, полстраны чем то торгует и чтото держит на складах.
1С например, мой склад, и еще куча всего менее известного.
Из опенсорсных - посмотри odoo community - очень классная erp для твоих целей избыточная, но склады умеет из коробки сразу так как надо учитывать, я там смотрел как сделан каталог, когда в своем проекте делал, у них можно поучится, там довольно хорошо все вот эти возникающие вещи уже учтены.
А так систем учета товаров реально миллион если загуглить.
Евгений Решетников, у 4-го варианта будут очень большие проблемы, я когда в своем проекте делал каталог товаров сначала попробовал по этому варианту сделать, потом долго этот старшный костыль переделывал с ним в реальности потом невозможно работать.
Есть EAV у которого начиная с определенного количества товаров, возникает проблема со скоростью. Обычно его берут как основу, но делают компромиссный вариант, например денормализация базы с использованием jsonb в postgresql
Посмотрите реализацию конструктора супер-типа, например, в CMS Modx - Migx.
Из коробки он делает именно то, что вы хотите. Администратор создает новый тип, который может включать несколько свойств, а может еще быть свойства-списки, причем, тоже кастомного типа.
Единственная проблема Migx - нужно учиться понимать концепцию этого конструктора и определенное время на обучение созданию структур. Он не имеет интуитивно понятный интерфейс, вы тоже не сделаете интерфейс лучше.
Простой
Средний
Средний
