Как лучше хранить и модифицировать json конфиг?

Question

[codercat]

Есть сервис для сборки приложений, на вход он принимает большой json-объект с большим количеством вложенностей:


Необходимо как-то хранить такие конфиги, изменять, добавлять новые параметры.

Была идея сделать всё на mysql'e из-за опыта работы с ним, создав таблички: projects, projects_design, projects_design_screens, projects_design_screens_blocks, .., связав их вместе ; но кажется, что это слишком неудобный вариант и пора узнавать что-то новое.

Сейчас рассматриваю mongo, но всё же хочется узнать мнение и опыт сообщества, прежде чем начинать делать основу.

Answer 1

[Alexander Litvinenko]

В монге это все сохранится одной командой, но база данных по одной узкой задачи не выбирается.

Comments

[codercat]

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

[Arris]

codercat: основная сущность проекта - работа с конфигами? :) ЧуднО

[codercat]

Arris: можно так сказать. Есть приложения, которые собираются на вот таких вот конфигах. Последний год эти конфиги собирались ручками, а сейчас захотелось сделать веб-мордочку, дабы изменять и передавать эти конфиги в тимсити для сборки аппы.

Answer 2

[Alex XYZ]

Это достаточно высокий и хороший уровень конфигурирования приложения. Из реальной жизни посмотрите на maven или grunt, у них то же самое. Особенно maven - максимум, что они можно выжать - более удобный способ отображения XML, например, в Eclipse или IDEA, чтобы было легче воспринимать структуру файла. К тому же само наличие файла конфигурации уже повышает уровень восприятия вашего приложения. Я бы не стал задумываться о "программировании" конфигурации и раскладывания его параметров по базе, т.к. такие суть именно в том, что такие конфиги и должны храниться в одном месте, а не раскидывать значения по таблицам, чтобы отдельным процессом собираться в этот файл да ещё и с ошибками, возможно.

Comments

[codercat]

Видимо, вы не совсем поняли, или я. Этих конфигов много, а сервис - это как раз создание/изменение вот таких конфигов в удобной веб-морде, поэтому надо будет постоянно с ними работать/изменять.

[Alex XYZ]

codercat: Если быть занудой, то у вас написано "на вход он принимает большой json-объект", но про множество конфигов - ни слова. :)
Если вы думаете о переносе этого набора в GUI-интерфейс с базой, то тут придётся помучиться, потому что всплывут те же проблемы, которые есть у всех "веб-клиентов" - разделение доступа, безопасность/аутентификация/авторизация, ведение бд пользователей и всё это не имеет никакого отношения к самой задаче. Если вы рассматриваете вопрос о nosql, то тут есть общая проблема, которая так же не относится к вашей задаче, а решить её придётся - транзакции пока только на уровне одного документа, т.е. если вы решите сохранить два документа и с одним что-то пошло не так, а второй сохранился, то отменить сохранение второго документа и вернуться к исходному состоянию двух документов уже не получится. Вот так "лёгким" внедрением mongo базы в задачу вы получите ворох проблем, решение которых может быть неоправданно дорогим и за которые может и нет смысла браться.

Но это не значит, что ничего не надо делать. Иногда решение находится очень неожиданно и совсем не там где ищете.

[codercat]

Захаров Александр: я очень сомневаюсь, что конфиги будут меняться часто. Он изменился, отправили его на сборку приложения, приложение собирается ~10 минут.
Всё-таки, что порекомендуете? Могу полностью и подробно описать задачу, но, как мне кажется, и этого вполне достаточно :/

[Alex XYZ]

codercat: В общих чертах да, понятно, но для полноты картины киньте мне на почту парочку-тройку примеров конфигов на почту.
Если у вас названия полей в JSON являются предопределёнными, я бы озаботился отображением и привязкой GUI для некоторых узлов JSON-а. Ну, как пример, что-то типа angular-овского TODO-list, например, к ветке design.main_screen.block_lines, тем более что рисовать иерархические меню на основе JSON у angular "в крови". И так постепенно покрыл бы GUI весь JSON (или его необходимую/минимальную часть/части). А на выходе сделал кнопку "получить json" и пока просто новый json-файл или просто текст.