Модель хранилища данных приложения
Я ищу, как создать эффективную модель, которая будет отвечать требованиям, которые я поставлю ниже. Я пытался использовать gcloud-node, но заметил, что у него есть ограничения в отношении согласованности чтения, ссылок и т. Д. Я бы предпочел написать это nodejs, но он был бы открыт для записи в java или python, если это улучшило бы мою модель. Я строю вокруг новой модели ценообразования, которая появится 1 июля.
Мое приложение состоит из закрытой почтовой системы. По сути, происходит регистрация пользователей на сайте. Эти пользователи могут подружиться. Затем они могут отправлять электронные письма друг другу.
Компоненты приложения:
Пользователи - неограниченное количество пользователей может присоединиться.
Друзья - Пользователь может иметь 200 подтвержденных друзей и 100 ожидающих запросов на добавление в друзья. Когда список друзей найден, в нем должно быть указано имя друга. (Мне также нужно будет получить идентификатор друзей, чтобы я мог использовать его на стороне клиента для создания электронных писем).
Электронные письма - пользователи могут отправлять электронные письма своим друзьям и получать электронные письма от своих друзей. Затем пользователь может просматривать все свои отправленные письма независимо (отправленный ящик) и все полученные письма независимо (входящие). Они также могут просматривать электронные письма, отправленные между ними и заказами друзей по самым новым. В письмах должны быть указаны имена отправителей и получателей. Как только письмо прочитано, оно должно быть помечено как прочитанное.
Моя модель выглядит примерно так, но, как вы видите, это неэффективность.
Типы хранилища данных:
USER
-email (id) //The email doesn't need to be the id, but I need to be able to retrieve users by their email
-hash_password
-name
-account_status
-created_date
FRIEND
-id (auto-generated)
-friend1
-friend2
-status
EMAIL
-id (auto-generated)
-from
-to
-mutual_id
-message
-created_date
-has_seen
Процедуры подачи заявки:
Регистрация - Получить операцию, чтобы увидеть, существует ли пользователь с этим адресом электронной почты. Если не вставляет ключ.
Логин - Получить операцию, чтобы получить пользователя на основе электронной почты. Если существует, извлеките hash_password из объекта и сравните с пользовательским вводом.
Отправить запрос на добавление в друзья - данные о друзьях будут записываться дважды для каждого отношения. Затем, используя индекс для Friend1 и индекс для статуса, я опрошу всех друзей для пользователя и отфильтрую только тех, которые "ожидают". Затем я посчитаю этих друзей и посмотрю, не старше ли они X. Опять сделаю это для другого пользователя. Если они оба не превышают ожидаемый лимит, я вставлю запрос на добавление в друзья. Это должно выполняться в транзакции.
Примите запрос на добавление в друзья - данные о друзьях будут записываться дважды для каждого отношения. Затем, используя индекс для Friend1 и индекс для статуса, я опрошу всех друзей для пользователя и отфильтрую только тех, которые ожидают. Затем я посчитаю этих друзей и посмотрю, не старше ли они X. Опять сделаю это для другого пользователя. Если они оба не превышают ожидаемый лимит, я изменю статус обеих организаций на принятые в качестве транзакции.
Показать подтвержденных друзей - данные о друге будут записываться дважды для каждого отношения. Затем, используя индекс для Friend1 и индекс для статуса, я опрошу всех друзей для пользователя и отфильтрую только тех, которые приняты. Не уверен, как я покажу имена друзей (например, что произойдет, если пользователь изменил свое имя, это должно быть отражено во всех отношениях друзей и электронных письмах!).
Показать ожидающих друзей - данные друзей будут записываться дважды для каждого отношения. Затем, используя индекс для Friend1 и индекс для статуса, я опрошу всех друзей для пользователя и отфильтрую только тех, которые ожидают. Не уверен, как я покажу имена друзей (например, что произойдет, если пользователь изменил свое имя, это должно быть отражено во всех отношениях друзей и электронных письмах!).
Просмотр отправленных электронных писем. Используя индекс свойства from, я бы запросил все отправленные электронные письма от пользователя 5 за один раз, упорядоченный по методу созданной_даты (сначала самой новой). (например, что произойдет, если пользователь изменил свое имя, это должно быть отражено во всех отношениях друзей и электронных письмах!).
Просмотр полученных электронных писем. Используя индекс свойства to, я бы запросил все полученные электронные письма пользователю 5 за один раз, упорядоченный по методу созданной_даты (сначала самой новой). Когда электронное письмо будет просмотрено, оно обновит свойство сущностей has_seen до true. (например, что произойдет, если пользователь изменил свое имя, это должно быть отражено во всех отношениях друзей и электронных письмах!).
Просмотр электронных писем между двумя пользователями. Для запроса взаимных электронных писем используется индекс взаимного идентификатора, основанный на [lower_lexicographic_email]:[upper_lexicographic_email]. Заказано по новейшей, 5 за один раз. (например, что произойдет, если пользователь изменил свое имя, это должно быть отражено во всех отношениях друзей и электронных письмах!).
Создать электронную почту - Используя Friend1 и индекс статуса, я подтверждаю, что пользователь является друзьями. Если они друзья, я вставлю письмо.