有一种使用 SimpleDB 的方法,但它并不优雅,它更像是一种 hack,因为它需要您在提交项目中人为地复制 userid 属性。
这是基于这样一个事实,虽然每个 IN 谓词只能进行 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 个您不关心的属性。
从数据模型的角度来看,这显然是一个 hack。但是话虽如此,对于拥有 400 名或更少朋友的用户来说,它正是您想要的:一个查询,因此您可以按日期或其他条件进行限制,按最近的排序,翻阅结果等。不幸的是,容量400 个将无法容纳所有 facebook 用户的朋友列表。因此,您可能仍然需要为大型朋友列表实现多查询解决方案。
我的建议是,如果 SimpleDB 满足您的应用程序的需求,但此问题除外,那么请考虑使用 hack。但是如果你需要反复做这样的事情,那么 SimpleDB 可能不是最好的选择。