Я делаю простое приложение для склада. Соответственно мне нужно хранить в базе Разделы и Элементы склада.
В целом моя задача напоминает хранение в базе файловой системы
Сейчас это выглядит так:
Есть таблица FOLDERS в ней две колонки
PATH и NAME
Она нужна для того что бы когда приложение делает запрос например на чтение папки - проверялось существует ли такая папка или нет
Пример:
read '/'
выводит все папки (NAME) у которых PATH = '/'
Файлы каждой папки я храню в отдельной таблице
Например:
В таблице FOLDERS есть
PATH -> '/'
NAME - > 'FOLDER1'
Для этой папки соответственно есть таблица '/FOLDER1'
В таблице FOLDERS есть
PATH -> '/FOLDER1/'
NAME - > 'SUBFOLDER1'
Для этой папки соответственно есть таблица '/FOLDER1/SUBFOLDER1'
Сначала я пробовал держать всё в одной таблице и просто для каждого элемента
склада указывать путь в колонку 'PATH'. Но возникали сложности при обработке вариантов, что
пользователь например удаляет папку (проверить что папка уже существует, удалить все содержимое папки соответственно все подпапки и файлы и т.д.)
В общем можно ли как то это всё упростить? Может уже есть какие то готовые решения?
Есть несколько вариантов хранения иерархических данных в реляционной БД. Выбор зависит в основном от запросов клиентов и требований к производительности.
Если хотите разобраться в вопросе и сделать осознанный выбор, вот немного теории (и практики):
Ну потому что это не файлы. Я "Грубо" назвал их файлами, потому что принцип похожий.
Допустим есть элемент Гвозди в разделе /Склад/Метизы
У него есть значения ID, NAME, VALUE, TYPE и т.д.
Или вы предлагаете мне хранить в элементы в самой файловой системе вместо БД?
Типа {Рабочая папка}/Склад/Метизы/Гвозди.json и в нем сведения об элементе
Простой
