Базовый дизайн схемы для уведомлений / каналов / запросов? - PullRequest
4 голосов
/ 01 ноября 2010

Я проектирую социальную сеть и хотел узнать, нахожусь ли я на правильном пути.У меня есть Уведомления, Запросы и Живые каналы на сайте.Подобно тому, что мы видим на большинстве сайтов в настоящее время.Для их проектирования я предполагаю, что это НЕ отдельные компоненты, а все они вытекают из одного и того же компонента Activity?

В системе есть, скажем, 200 возможных действий с участием 30 объектов.40 действий могут иметь уведомления, 70 могут иметь каналы, 10 могут иметь запросы.Таким образом, я предполагаю, что они будут частью таблицы поиска действий, которая - имеет ли активность столбцы Feed, Notification, Request as Boolean.Если да, то текст по умолчанию для всех 3 (Лента, Уведомление, Запрос) для пользователя, например, «ИМЯ прокомментировал фотографию».Другим столбцом будет FK для таблицы поиска объектов, чтобы сопоставить объекты с действиями.

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

Один из возможных вариантов использования подобен уведомлениям: система может иметь 40 доступных, но пользователь может выбрать только 10 из них.Таким образом, будет отдельная таблица пользовательских настроек для хранения пользовательских настроек.

1 Ответ

0 голосов
/ 05 сентября 2012

То, что ты делаешь, звучит для меня вменяемым.В этом случае отношение активности можно использовать.Большие вопросы окружают масштаб, но их можно решить с помощью db-решений (например, Postgres-XC на Postgres).

Я не видел очевидного способа улучшить реляционный дизайн там.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...