SimpleDB でそれを行う方法はありますが、洗練されたものではありません。送信アイテムで userid 属性を人為的に複製する必要があるため、ハックのようなものです。
これは、IN 述語ごとに 20 の比較しかできないが、それぞれが異なる属性を指定する場合、 20 の IN 述語を持つことができるという事実に基づいています。したがって、フォームの送信項目に追加の合成属性を追加します。
userID='00123' userID_2='00123' userID_3='00123' userID_4='00123' ... userID_20='00123'
それらはすべて、特定の提出に対して同じ値を持ちます。次に、1 つのクエリで最大 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 人以下のユーザーの場合、まさにあなたが望むものを提供します: 1 つのクエリで、日付やその他の基準で制限したり、最近のもので並べ替えたり、結果をページスルーしたりできます。残念ながら、容量of 400 では、すべての Facebook ユーザーの友達リストに対応することはできません。そのため、大規模なフレンド リストに対しても、同じようにマルチクエリ ソリューションを実装する必要がある場合があります。
この問題を除いて、SimpleDB がアプリのニーズに合っている場合は、ハックの使用を検討してください。しかし、このようなことを繰り返し行う必要がある場合、SimpleDB はおそらく最良の選択ではありません。