В каком виде хранят данные Гугл-документы и похожие сервисы?
Хочу в целях тренировки написать похожий сервис. Упрощённый, конечно. Интересно, в чем и как хранить тексты. Только у меня будут не текстовые документы, а что-то вроде таблиц. Вот пытаюсь понять, как в БД организовать структуру данных.
Суть: Годы-месяцы-дни-план на день в виде таблицы.
Приложение должно определять сегодняшний день, подгружать план на день, показывать данные таблицей, предоставлять юзеру возможность править текст в ячейках и т.д.
В общем, вопрос, как организовать БД? Или хранить на севере в джейсонах?
1) Разработка формата хранения и обработки диаграмм планирования (Ганта?)
2) Разработка API для отображения этих данных и редактирования в браузере (front-end)
3) Back-end и подсистема хранения. Варианты : файловая система или база.
Мне кажется что 1 пункт - самый важный. Он определяет для 2х следующих пунктов как работать. Во первых что будет внутри диаграммы? Будет ли это 1 документ или сет связных между собой документов. Будет ли документ версионироваться внутри (как Office документы которые хранят историю изменений). Формат. JSON/XML/yaml бинарные форматы BSON, фреймворки бинарной сериализации такие как Apache Thrift, Avro, Protobuf. Будет ли документ блочный или поточный. Блочный например позволяет подгружать данные частично. Как таблица в БД.
Вобщем если-бы я разрабатывал формат - то нарисовал-бы сначала на бумаге картинку. Потом описал спецификацией просто все что есть. Годы-месяцы. Задачи. Исполнители. События. Алёрты. Напоминалки. И вот от этого бы делал.
mayton2019, однако, слишком сложно, буду простит... ээ.. я всего этого не знаю. Решил просто open server с мускулем поднять. Пока так попробую, представление и движок настрою. А потом буду дальше в форматы углубляться... Или не буду... Я блин, с каждой задачей, которую сам себе ставлю, натыкаюсь на всё большее количество всяких нюансов. И за подробное изучение какого из них взяться, не могу решить. Хотел бы уже к какой-нибудь команде примкнуть, чтобы сфокусироваться на конкретных задачах и стеке... Но не берут, к сожалению.
Получается, пока сам для себя играюсь.
Только не пытайтесь в базе хранить буквальное представление ежедневника как двумерной сетки из квадратиков - где пишут заметки на определенный день. Сетка ежедневника - это просто удобная форма вывода данных, но не способ их хранения.
Хранится это все будет, скорее всего линейно и банально списком заметок с заданными начальными и конечными интервалами:
Таблица заметок:
id - идентификатор заметки
begin_date - начало интервала
end_date - конец интервала
comment - заметка
Вот это минимум, что будет содержаться в базе данных в ее таблице.
А уже как будете получать данные этой таблицы и строить представление по дням, рисовать календарик - это уже не задача СУБД, а приложения, которое будет использовать эти данные.
alexalexes там фишка в том, что каждая заметка - это таблица с тремя разделами... в обсчем, я пока решил сделать так.
Год - это новая бд. Каждая таблица - это день. В нём поля id, First, second, third.
В id ключ, понятное дело. А дальше - да, как двумерная таблица. Первая ячейка, вторая, третья. Начало раздела - это заголовок, который повторяется в каждом из трёх полей.
Например
Заголовок Заголовок заголовок
текст текст текст
....
заголовок 2 заголовок 2 заголовок 2
текст текст текст
Таблица в СУБД, и то что вы представляете в качестве таблицы (сущности) на уровне бизнес-логики приложения - это разные вещи. Сущность на уровне бизнес-логики не будет один в один укладываться в такую же единицу в терминах СУБД. Таблицы в СУБД используют реляционный подход, который не соотносится с сущностным подходом. Этот разрыв требует от разработчика определенного навыка анализа предметной области, чтобы преобразовывать сущности в отдельные таблицы (так называемый процесс нормализации данных). Вам нужно с одной стороны понять, как работает реляционная алгебра в СУБД, как правильно создаются объекты в ней (таблица - это только один из объектов, есть еще связи, триггеры, последовательности, представления и т.д.) и как их правильно используют. А с другой стороны, нужно научиться анализу предметной области, выделять сущности, классифицировать их, видеть какие вспомогательные сущности должны быть созданы, как их перенести на объекты СУБД (не только таблицы). Это в купе довольно сложно объяснить в одном комментарии, но между СУБД и приложением есть определенная пропасть, и навыки программиста как раз направлены, чтобы пробросить мост над ней.
