Я работаю над приложением, которое требует показывать разные сообщения на временной шкале пользователя (что-то вроде Twitter).
Временная шкала пользователя состоит из следующих элементов:
Отчеты какой пользователь создал
Отчеты, которые создал другой пользователь, и попадают под радиус его «местоположения предупреждения»
- Отчеты других пользователей, за которыми он / она следует (Даже если этот отчет не попадает в радиус «местоположения оповещения»)
- Отчет, который публикуется / переписывается пользователем, следует (даже если этот отчет не попадает в радиус «местоположения оповещения»)
- Сообщает, какой другой пользователь создал и попадает под его / ее радиус «текущего местоположения», когда он путешествует.
- Следить за уведомлением - Когда кто-то начал следовать за ним / ее
- Уведомление о сообщении - Когда кто-то отправил ему / ей сообщение
Примечание: - Как только отчет появится на временной шкале пользователя, он не исчезнет, даже если пользователь выйдет за пределы радиуса местоположения или изменяет «место оповещения». Он исчезнет только тогда, когда он будет удален или помечен как неподходящий.
Требование: Мне нужна оптимальная схема БД (с запросом SELECT), чтобы я мог показывать вышеупомянутые сообщения на временной шкале пользователя.
Вот моя текущая структура БД:
Table: users
UserID (PK)
email
password
Table: alert_locations
alertLocationID (PK)
user_id (FK)
latitude
longitude
radius
Table: followers
follower_id (FK)
following_id (FK)(follower_id + following_id) = PK
Table: reports
reportID (PK)
reported_by_id (FK)
location
latitude
longitude
parent_id (FK- For retweet relations)
Теперь, учитывая вышеприведенные случаи временной шкалы, я имею в виду таблицу timeline
со структурой, показанной ниже:
Table Name: timeline
timelineID (PK)
reference_id (Can be report_id or follower_id or message_sender_id)
user_id (FK)
title
type (1:For Report, 2:Follow, 3:Message)
Итак, при создании отчета для каждого пользователя вставляется новая строка в таблице timeline
, которая имеет право просматривать этот отчет. Используя эту таблицу, я могу запросить все типы сообщений для временной шкалы пользователя. Но, как я вижу, этот подход, похоже, имеет проблемы с масштабированием, и он не выглядит мудрым, чтобы вставлять количество n строк в таблицу timeline
каждый раз, когда создается новый отчет.
Есть ли что-нибудь еще лучше решение для достижения этого?