Есть способ сделать это с SimpleDB, но это не элегантно, это скорее хак, так как требует искусственного дублирования атрибута userid в ваших элементах представления.
Это основано на том факте, что хотя вы можете иметь только 20 сравнений на один предикат IN, вы можете иметь 20 предикатов IN , если каждый из них называет разные атрибуты. Поэтому добавьте дополнительные синтетические атрибуты к элементам представления в форме:
userID = '00123' userID_2 = '00123' userID_3 = '00123' userID_4 = '00123' ... userID_20 = '00123'
Все они имеют одинаковое значение для данного представления. Затем вы можете получить представление до 400 друзей с помощью одного запроса:
SELECT * FROM submissions
WHERE userID IN('00120','00121',...,'00139') OR
`userID_2` IN('00140','00141',...,'00159') OR
`userID_3` IN('00160','00161',...,'00179') OR
`userID_4` IN('00180','00181',...,'00199') OR
...
`userID_20` IN('00300','00301',...,'00319')
Вы можете заполнить 19 дополнительных атрибутов во время создания представления (если у вас есть запасные атрибуты), и не похоже, что пользователь представления когда-либо изменится. Также вы можете явно указать имена возвращаемых атрибутов (вместо использования *), поскольку теперь у вас будет 19 из них, которые вам не нужны в возвращаемом наборе данных.
С точки зрения модели данных это явно подделка. Но, сказав это, он дает вам именно то, что вы хотели бы, для пользователей с 400 друзьями или менее: один запрос, чтобы вы могли ограничить по дате или другим критериям, сортировать по самым последним, просматривать страницы и т.д. К сожалению, емкость из 400 не будет соответствовать спискам друзей всех пользователей Facebook. Так что вам, возможно, все же понадобится реализовать решение с несколькими запросами для больших списков друзей.
Мое предложение заключается в том, что если SimpleDB соответствует потребностям вашего приложения, за исключением этой проблемы, то подумайте об использовании хака. Но если вам нужно делать такие вещи неоднократно, то SimpleDB, вероятно, не лучший выбор.