Похоже на типичное отношение «многие ко многим» - я не вижу каких-либо ограничений в том, что вы хотите, что позволило бы сэкономить пространство по сравнению с типичной идиомой реляционных БД для них, то есть таблицы с двумя столбцами (оба внешних ключи, один для пользователей и один для твитов) ... поскольку текущие подписчики могут и действительно изменяться, отправляя твит всем подписчикам, которые актуальны на момент публикации (я полагаю, это то, что вы имеете в виду?) означает означает, что добавление такого количества (очень коротких) строк в эту таблицу взаимосвязей (альтернатива сохранения истории наборов подписчиков с метками времени, чтобы вы могли восстановить, кто был подписчиком в любой заданный момент публикации твита, со временем определенно выглядит хуже и не существенно лучше в космосе).
Если, с другой стороны, вы хотите проверять подписчиков во время просмотра (а не во время публикации), то вы могли бы создать специальный идентификатор пользователя искусственно означает «все подписчики текущего пользователя» (точно так же, как у вас будет одно значение «все пользователи в Твиттере»); необходимый SQL, чтобы сделать поиск быстрым, в этом случае выглядит волосатым, но выполнимым (СОЮЗ или ИЛИ со «всеми твитами, за которые я являюсь последователем автора, а твит читается [искусственным идентификатором пользователя, представляющим] всех последователей» «). Я не буду углубляться в этот лабиринт SQL до тех пор, пока вы не подтвердите, что вы имеете в виду именно этот специфический смысл (а не простой, который кажется мне более естественным, но не позволяет любая экономия места на таблице отношений для действия «опубликовать твит всем подписчикам»).
Редактировать : ФП уточнил, что они означают подход, который я упоминаю во втором абзаце.
Тогда предположим, что userid является первичным ключом таблицы Users, таблица Tweets имеет первичный ключ tweetid и внешний ключ author для ИД пользователя каждого твита, Followers table - это типичная таблица отношений «многие ко многим» с двумя столбцами (оба внешних ключа в Users) follower и followee, а таблица Canread - не очень типичная «многие ко многим» таблица отношений, все еще с двумя столбцами - внешний ключ в Users - это столбец reader, внешний ключ в Tweets - это столбец tweet (phew ;-). Два специальных пользователя @everybody и @allfollowers определены с вышеуказанными значениями (так что публикация всем, всем подписчикам или «только мне») добавляет только одну строку к Canread - только выборочное размещение в определенном списке из N человек добавляет N строк).
Таким образом, SQL для набора идентификаторов твитов, которые пользователь @me может прочитать, я думаю, что-то вроде:
SELECT Tweets.tweetid
FROM Tweets
JOIN Canread ON(Tweets.tweetid=Canread.tweet)
WHERE Canread.reader IN (@me, @everybody)
UNION
SELECT Tweets.tweetid
FROM Tweets
JOIN Canread ON(Tweets.tweetid=Canread.tweet)
JOIN Followers ON(Tweets.author=Followers.followee)
WHERE Canread.reader=@allfollowers
AND Followers.follower=@me