Пример БД в виде отдельных JSON файлов для C#?

Question

[lucky_guy228]

Вопрос заключается в том, что мне нужна база данных, которая не будет хранится одним файлов (как в Sqlite), а в виде кучи файлов json, где отдельная таблица это папка, а запись в таблице это отдельный Json файл. Есть ли для этого готовые решения?

Comments

[Василий Банников]

А чем однофайловые бд не угодили. Типа того же sqlite или litedb?
А то что ты описал - оно никаких плюсов нормальной СУБД не несёт (нет индексов например), но реализуется достаточно просто

[rPman]

Скажи зачем тебе такое странное решение?

[Модератор]

Не надо лепить как можно больше тэгов.
См.п.3.1 Регламента. Также обратите внимание на п.3.4

[Алан Гибизов]

Ощущение, что это xy проблема.

Answer 1

[Denis Melnikov]

Чем вам mongo не угадила ?
Либо можно HarperDB , у нее прям REST APi и можно прямые SQL запросы.

Comments

[lucky_guy228]

Может бы и угодила, не сталкивался с ней)
Спасибо за много вариантов, рассмотрю их

Answer 2

[Василий Банников]

1. В такой СУБД нет никакого смысла, по тому нет никаких готовых библиотек
2. Реализуется очень просто - ты бы быстрее свой велосипед сделал, чем получил бы ответ здесь.

Comments

[lucky_guy228]

1. Есть, если хочешь, чтобы в гите все работали с ней и никто друг другу не мешал. Это нужно больше использовать как хранилище конфигов нежели БД, где будут например храниться пользовательские данные
2. Так можно ответить на любой вопрос =)

[Василий Банников]

lucky_guy228,
1. Вроде такое уже есть. Ща поищу

[Василий Банников]

lucky_guy228, может это?
https://www.nuget.org/packages/Microsoft.Extension...

[lucky_guy228]

Тоже полезно. Спасибо )

[Василий Банников]

lucky_guy228, ещё для конфигов можешь посмотреть в сторону consul + vault

Answer 3

[mayton2019]

Лет 15 назад когда я работал в *телекомах мы строили такую систему. Но JSON тогда не использовался. У нас был XML основной формой сериализации данных. Что могу сказать. Проблем с такой системой много. Если с загрузками-выгрузками еще нормально. То с пишущими транзакциями и с конкуренцией - все очень плохо. Файловые системы того времени FAT/NTFS4 плохо реагировали на блокировки и процессы у нас часто висли и их приходилось убивать через таск-менеджер прям на сервере. Позже я для себя пришел к выводу что эффективную БД так пострить невозможно. Нужен WAL на диске, кеш активных страниц и некий координатор блокировок в главном мастер-процессе. Чуть позже я сам для себя узнал что это и есть составные части почти любой современной DBMS.

Тоесть если вы все таки решите делать БД на файлах то это будет либо очень ограниченная и медленная БД. Либо этот проект плавно перерастет в самописную DBMS на "крупных файлах". Если у вас конечно будет энтузиазм расследовать performance issues и улучшать продукт.

Comments

[lucky_guy228]

Привет! Спасибо за твой опыт, очень интересно) Я не планирую ее использовать для большого хранилища с большим количеством таблиц и связей. Это больше нужно для большой кучи конфигов.

[mayton2019]

lucky_guy228, обратите внимание на YAML. Он - более человеко-читаемый.

Answer 4

[rPman]

Боюсь ты такое странное решение не найдешь готовым

База данных это не сколько хранение - но поиск (и атомарность записи с поддержкой многопоточности). И если хранение реализовывать и не надо (на все по 1-2 строчки кода) то с поиском (индексами) и многопоточностью придется повозиться, и с файлами этим заниматься точно никому не надо.

p.s. Для .net у майкрософта есть набор классов DataSet, практически полноценная in memory база данных, добавляй к нему свой сериализатор (по умолчанию там есть xml дамп, меняющий формат от вересии к версии), по уму делов там не много зато с DataSet через DataBinding все работает из каропки

Comments

[lucky_guy228]

Я и не собираюсь это использовать, как БД для хранения серьезных данных. Это больше нужно для создания кучи конфигов, с которыми будет удобно работать в гите и не мешать друг другу (т.к. они существуют как отдельный файл)

[rPman]

т.е. тебе для себя, в один процесс и тебе нужна БИБЛИОТЕКА чтобы записывать json в файлы?
System.Text.Json.JsonSerializer

[lucky_guy228]

rPman, Как сериализовать Json я знаю (спасибо Newtonsoft). Писать для редактирования такой структуры БД клиент мне не очень хочется. Денис Мельников выше написал про то, что мне нужно ). Вот сейчас узнал, что это называется "Документоориентированная СУБД" и это как раз то, что мне нужно

[rPman]

lucky_guy228, где в его ответе инструменты хранения данных объектов в json?
о какой клиенте, что писать, какая структура?

Ты принимаешь для себя какое то правило именования файлов (имя каталога и имя файла могут являться неким индексом быстрого доступа к данным, при этом добавляя уровень категории) и просто пишешь и читаешь файл по указанному пути, весь код - это проверка отсутствия каталога при записи файла и его создание при необходимости.

[lucky_guy228]

Хорошо... Зайду с другой стороны. Как эти json`ы будет редактировать человек, который никакого отношения к программированию не имеет?
Я в своем вопросе не писал о том, КАК читать в своем приложении, мне нужна была вещь, которая поможет организовать Json файлы и позволить их редактировать в каком-нибудь понятном интерфйесе )

[rPman]

рукалицо

Твой вопрос изначально

отдельная таблица это папка, а запись в таблице это отдельный Json файл

чтобы это реализовать при втоих условиях не нужно ничего кодить, не нужно никаких библиотек.

json - human readable формат, при наличии форматирования можно редактировать в любом текстовом редакторе, многие поддерживают не только раскраску синтаксиса но и валидацию... существуют просмотрщики (да и редакторы) которые позволяют смотреть на json структурно (например сворачивать подобъекты и массивы, ну пример браузерный отладчик) но на практике это удобно только для мелких изменений и в конечном счете нужен не только файл но какое то описание его формата (где какие элементы, какого типа, какие ограничения, например для списков и т.п. - schema) вот например, советую осознать на сколько это неудобно в некоторых случаях.

p.s. исторически майкрософт .net проекты конфиги хранят в xml файлах (тоже кстати human readable), встроенная поддержка, разные уровни видимости, поддержка при деплое и т.п.

Answer 5

[lucky_guy228]

Ребят! Напишу для всех тех, кому лень читать комментарии. Это не требуется для огромной БД вообще никак, я не собираюсь хранить какие-либо сложные данные таким образом. Это нужно для хранения группы конфигов и чтобы любой разраб(и человек далекий от разработки) мог в своей ветке спокойно добавлять записи в таблицу (в удобном графическом интерфейсе) и не это не вызывало конфликтов, как это могло бы быть с однофайловой бд.
Я получил ответ на свой вопрос, поэтому комментарии по типу "а че зачем" или объяснять мне, как считывать "json" не надо. Давайте не будем токсичными )
Спасибо Denis Melnikov за ответ и mayton2019 за интересный опыт