База данных RTPlatform

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

Чтобы не тратить время на разработку серверной части проекта, для работы с этой базой данных, для разработчиков мобильных приложений имеется отличное решение от Google — Firebase. В его составе есть та самая Realtime Database, которая предоставляется в виде услуги, т.е. платишь за потребление ресурсов и не думаешь о работоспособности сервера. Клиент с сервером обмениваются через Socket, отсюда и молниеностная скорость на изменение данных. Удобство в том что разработчик мобильных приложений пишет или подписывается на данные, а не разрабатывает в принципе сервер.

Структура базы данных RTPlatform

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

Объявления [ads] — список объявлений, ключом является уникальный id объявления. Обязательные поля:

  • category — категория объявления;
  • dateCreate — дата создания;
  • job — заголовок объявления;
  • user — id пользователя.

Категории объявлений [categories] — массив категорий объявлений:

  • name — название категории;
  • description — краткое описание под категорией.

Диалоги пользователей [dialogs] — массив сообщений между пользователями. Ключем является соединение двух индентификаторов пользователе, отсортированных по алфавиту: id1_id2. Во вложенном ключе messages хранится массив сообщений с уникальными ключами сообщения:

  • dateCreate — дата и время создания сообщения;
  • text — текст сообщения;
  • user — id пользователя автора.

Мастера [masters] — список мастеров. Ключем является id пользователя, т.к. профиль мастера может быть один. Профиль состоит из:

  • dateCreate — дата и время создания;
  • fio — фамилия, имя, отчество;
  • phone — телефон мастера;
  • user — id пользователя.

Уведомления [notifications] — список персональных уведомлений пользователя. Ключем является id пользователя. Вложенно идут ключи индентификатора уведомления, например, messages_key, где

  • messages — тип уведомления, в даном случае сообщение в диалоге;
  • key — уникальный ключ, в данном случае id пользователя отправившего сообщение.

При такой конструкции ключа и его уникальности в списке уведомлений будет одно активное уведомление от конкретного человека.

Так же бывает уведомление о новом предложении: Ad_<id объявления>_<id пользователя>.

Поля сообщения:

  • active — уведомление новое и нужно пользователя об этом уведомить, после уведомления пользователя меняется на false;
  • dateCreate — дата и время создания;
  • isRead — уведомление прочитано и не должно отображать бейджа о новых уведомлениях;
  • subject — заголовок уведомления;
  • text — текст уведомления;
  • url — ссылка на экран, который надо открыть при переходе с уведомления;
  • user — id пользователя.

Токены Push-уведомлений [push] — массив токенов Push-уведомлений для отправки персональных уведомлений. Ключом является id пользователя, а в поле token храниться токен для отправки Push-уведомлений.

Предложения на объявление [responses] — массив предложений на объявление. Ключом является id объявления, затем ключ id пользователя отправившего предложение. Состав данных предложения:

  • dateCreate — дата и времясоздания;
  • response — предложение;
  • user — id пользователя.

Настройки сервиса [setting]

Содержит текстовые материалы для раздела настроек, about — хранит информацию раздел «О сервисе», а agreement — пользовательское соглашение. В данных полях можно применять html теги для форматирования.

Правила безопасности

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

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

Например, токены Push-уведомлений, база данных разрешает писать в свою ветку пользователя push/<id пользователя>, а читать никому не разрешает. Делается это двумя простыми правилами:

Объявления тоже нужно разрешить править только самому пользователю, а остальным лишь читать.

В ключе диалога есть два пользователя и нужно проверить вхождения при доступе к этой ветке:

С предложениями самое интересное правило:

В первом правиле чтения, нужно разрешишь писать и читать владельцу объявления, идет проверка в корневом хранилище ветки объявлений, того самого объявления что и предложение (idAd) что в поле user. Второе правило позволяет читать и писать свое предложение.

Итоги

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