В каком виде хранят данные Гугл-документы и похожие сервисы?

Хочу в целях тренировки написать похожий сервис. Упрощённый, конечно. Интересно, в чем и как хранить тексты. Только у меня будут не текстовые документы, а что-то вроде таблиц. Вот пытаюсь понять, как в БД организовать структуру данных.

Суть: Годы-месяцы-дни-план на день в виде таблицы.

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

В общем, вопрос, как организовать БД? Или хранить на севере в джейсонах?

Дополнительно:

База данных вполне сгодится. Обычный crud

Ответы:

Только не пытайтесь в базе хранить буквальное представление ежедневника как двумерной сетки из квадратиков - где пишут заметки на определенный день. Сетка ежедневника - это просто удобная форма вывода данных, но не способ их хранения.
Хранится это все будет, скорее всего линейно и банально списком заметок с заданными начальными и конечными интервалами:
Таблица заметок:
id - идентификатор заметки
begin_date - начало интервала
end_date - конец интервала
comment - заметка
Вот это минимум, что будет содержаться в базе данных в ее таблице.
А уже как будете получать данные этой таблицы и строить представление по дням, рисовать календарик - это уже не задача СУБД, а приложения, которое будет использовать эти данные.

• alexalexes там фишка в том, что каждая заметка - это таблица с тремя разделами... в обсчем, я пока решил сделать так.
  Год - это новая бд. Каждая таблица - это день. В нём поля id, First, second, third.
  В id ключ, понятное дело. А дальше - да, как двумерная таблица. Первая ячейка, вторая, третья. Начало раздела - это заголовок, который повторяется в каждом из трёх полей.
  Например
  Заголовок Заголовок заголовок
  текст текст текст
  ....
  заголовок 2 заголовок 2 заголовок 2
  текст текст текст

  и т.д.

  Мне всё логично и парсить удобно вроде =)

• Таблица в СУБД, и то что вы представляете в качестве таблицы (сущности) на уровне бизнес-логики приложения - это разные вещи. Сущность на уровне бизнес-логики не будет один в один укладываться в такую же единицу в терминах СУБД. Таблицы в СУБД используют реляционный подход, который не соотносится с сущностным подходом. Этот разрыв требует от разработчика определенного навыка анализа предметной области, чтобы преобразовывать сущности в отдельные таблицы (так называемый процесс нормализации данных). Вам нужно с одной стороны понять, как работает реляционная алгебра в СУБД, как правильно создаются объекты в ней (таблица - это только один из объектов, есть еще связи, триггеры, последовательности, представления и т.д.) и как их правильно используют. А с другой стороны, нужно научиться анализу предметной области, выделять сущности, классифицировать их, видеть какие вспомогательные сущности должны быть созданы, как их перенести на объекты СУБД (не только таблицы). Это в купе довольно сложно объяснить в одном комментарии, но между СУБД и приложением есть определенная пропасть, и навыки программиста как раз направлены, чтобы пробросить мост над ней.