0
私は、人々が一日のギグのためにユーザーを予約できる小さなサイトを構築しようとしています。私は流星からアカウントのパッケージを使用しています。私の計画は次のものを添付することです：mongodb /流星の可用性スキーマを設計する
user.availability: [
{
status: n, //where n is 0-# of status types (5 atm) : single char rather than float
date: ddmmyyy, //string as well, no need for time as its day long
job_id: {Job}
}, ...
]
ジョブはちょうど、いつ、何のような情報を持っています。
ニュートラル、使用可能、明示的に使用不可、予約済み、保留の5つの状態があります。ユーザーは当然ニュートラルであり、明示的に可用性を示す必要があります。彼らは、最初の3つの州の中から選ぶ：n、a、uそして、将来最大2週間の可用性を設定することだけが許されている。ジョブ「恩人」は、他の2つの可用性状態を設定するものです。私の中立状態は、db（user.availability配列）にレコードが必要ないことを意味します。
db.users.find({ availability: { status: 'a', date: { $in: search_dates_array }});
をし、ユーザがログインするには/サイトにアクセスしたとき、私は、現在の日付より前の日付のために、彼らが持っている任意の可用性の設定を拭くことができます。
このスタイルは、次のクエリのために私を設定します。非アクティブなユーザーは、はるかに長い間隔でプルーニングされます。
このソリューションは、最小限の情報量を格納し、特定のイベントによって引き起こされるメンテナンスをほとんど必要とせず、クエリが簡単であるという点で有益です。しかし、これがmongodbの強みを活用する正しい方法であれば、私は100％確信していません。私はこれに関する助けを感謝し、もし誰かがmongodbスキーマを最適化するための記事を（比較的）簡単に消化することを指摘できるなら、それはすばらしいでしょう。
ありがとうございます。
一見、これはうまく見えます。あなたは文字列として日付を保持しているので、日付検索を実行することはできませんが、2週間の水平線はそれほど重要ではありません。 1つのクエリは理想的なスキーマではありません。あなたは後で来るかもしれない他の質問について考える必要があります。先月は誰が働いたのですか？どのギグがキャンセルされたのかノーショーだったのか？ギグのための最高の人は誰ですか（スキルと近接性に基づいています）？ –
私たちの現在のニーズの多くは過去のものではなく、現在の日付より前の日付のレコードはほとんど削除されます。しかし、新しいシステムを導入すれば、新しい可能性が生まれます。将来の検索に役立つ可能性があるかどうかを確認するための質問をいくつか考えてみましょう。下のMikkelの提案をアカウントから取り除いても、これは意味をなさないはずです。 –