'Подписчики' и эффективность
Я разрабатываю приложение, которое вовлекло бы пользователей 'после' действия друг друга в смысле Твиттера, но я не очень опытен с базой данных/запросом, design/efficiency. Есть ли лучшие практики для управления этим, ловушки для предотвращения, и т.д.? Я заключаю, что это может создать очень большую нагрузку на дб если не сделанный правильно (или возможно даже затем?).
Если это имеет значение, вероятно, что люди будут 'следовать' только относительно небольшое количество людей (но у человека могут быть многие подписчики). Однако это не бесспорно, и я не хотел бы рассчитывать на него.
Любой совет с благодарностью получен.Спасибо.
4 ответа
Довольно просто и легко сделать с полной нормализацией . Если у вас есть таблица пользователей, каждый из которых имеет уникальный идентификатор, у вас будет таблица TABLE_FOLLOWERS со столбцами, USERID и FOLLOWERID , которые будут описывать все подписчиков для каждого пользователя как отношения один к одному ко многим.
Даже с миллионами ассоциаций на полуприличном сервере базы данных это будет работать хорошо и быстро, если вы используете хорошую базу данных (IE, а не MS-Access).
Вам, вероятно, следует прочитать http://highscalability.com/ и его статьи о том, как этим управляют крупные сайты.
Это зависит от того, сколько пользователей вам потребуется поддерживать; сколько подписчиков вы ожидаете от пользователей; и к какому типу финансирования / усилий по развитию вы ожидаете получить доступ, если ваши ответы на предыдущие вопросы окажутся оптимистичными.
Для небольшого проекта я бы, вероятно, проигнорировал базу данных, спроектировав приложение как простую объектную модель с объектами User , которые поддерживают List [followers] . Храните все это в ОЗУ для нормальной работы и используйте ORM для периодического сохранения в базе данных (возможно, postgresql или mysql).
Для более крупного проекта я бы вообще не использовал реляционную базу данных; но то, что я буду использовать, будет зависеть от конкретных деталей проекта.
Если вы только пытаетесь развить концепцию, используйте подход ORM; но имейте в виду, что это не масштабируется.
Модель довольно просто. Проблема в размере таблицы Subscription ; если имеется 1 миллион пользователей, и каждый подписывается на 1000, то таблица Subscription содержит 1 миллиард строк.
