Как хранить данные статьи?
 

На странице написания статьи можно динамически добавлять разделы.
К примеру, нажимаю на кнопочку "добавить раздел", появляется div, содержащий input type = "text" для ввода названия раздела, и еще textarea для ввода текста раздела.

У меня два варианта сохранить все это дело:

1) Создать таблицу razdely , каждый раздел записать туда отдельной строкой
|id | article_id | name | text |

2) Объединить все разделы в один JSON-объект и записать в единственное поле | content | таблицы статей.

и как-то душа лежит ко второму.

Правильно ли это?
Если да, то как реализовать?

Можно ли так?
1) создать пустой объект A
2) найти все div'ы, которые предназначены для разделов
3) для каждого div'а создавать объект вида
{ name: (данные из input type = 'text'),
text: (данные из textarea) } и записывать его в A

Получившийся в итоге объект отправлять на сервер при сабмите формы, а там записывать в бд.

Или есть лучшие способы?

Нет.

А как в таком случае будет правильнее?

Если |id | article_id | name | text | и реляционная база данных, то хранение в ней данных в виде строки, чем и является JSON, означает, что без очень большой крови в такой базе никогда не найти все статьи раздела или темы, не получить архивы статей под дате их добавления и т.п.

Надо ли еще что-то пояснять?

Я не знаю кто такие гайды и честно говоря и не хочу знать. Но если для них удобно держать данные в виде JSON, то причем тут реляционная СУБД? Какой смысл в ней, чтобы строки хранить? Ну так JSON можно и просто хранить и не только на сервере, но и на клиенте.

Ramundo,
на другом форуме попался этот же вопрос, причем трактовка его на 100% аналогична, без "гайдов" каких-то и прочего, о чем было написано в личку.

Поймите простую вещь - тип СУБД, организация в ней данных, то есть структура таблиц определяется не нажимаю на кнопочку "добавить раздел", появляется div, содержащий input type = "text" для ввода названия раздела, и еще textarea для ввода текста раздела, а типами данных, их назначением и структурой. А "нажимаю на кнопочку", это всего лишь пользовательский интерфейс к самой СУБД отношения не имеющий.

А вот это определение написания статьи можно динамически добавлять разделы и |id | article_id | name | text |, это уже ближе к структуре данных, к вопросам касающимся их представления в конкретной СУБД. И в данном случае речь идет о реляционной базе данных, для которых вместо структуры |id | article_id | name | text | впихнуть все в строку и поместить в базу, равноценно петле на шее. Это если понимать описанное вами как и следует.

Обязательно прочесть это и уяснить.

А если не важно все это, какие-то там гайды, для которых и нужно получать это как json-строки, а кто-то там с ними будут разбираться, то значит не ставьте вопросом "динамически добавляемые разделы, статьи в разделах.... и т.п.", иначе вас никто не поймет чего вам хочется. Если удовлетворяет хранение просто строк, значит и храните просто строки, не важно уже что там будет, это уже не забота СУБД, а того, кто ведает "гайдами".

Но есть СУБД, которые базируются и на JSON, типов баз данных много.