複数のバックエンド (現在は MySQL または XML) にフックできる PHP アプリがあり、MongoDB でも動作させようとしています。私が明らかに苦労している一見マイナーな問題の 1 つは、Mongo が '_id' を主キーの名前にすることを義務付けていることです。バックエンドは通常、アプリケーションによってかなりうまく抽象化されていますが、アプリケーションはかなり定期的に ID を操作する必要があるため、$result['id']今までうまく抽象化されていた のようなコードでアクセスします。
しかし今、「id」を主キーとして使用できない DB を (効率的に!) 処理しようとすることに直面しており、最適なオプションが何であるかわかりません。これまでに私が考えたことは次のとおりです。
Mongo の '_id' 値をそのままにして、アプリケーション変数
$idをバックエンドに、"id"または"_id"バックエンドに応じて設定します。アプリケーションは$id、ハードコードされた ではなく、 を使用して ID フィールドにアクセスする必要があります"id"。他のすべてのフィールドは、$result['user']and などの文字列名でアクセスされるため、これはアプリケーションの標準に違反することに注意してください。長所: 可能な場合は MongoCursor オブジェクトを直接返すことができるため、メモリ使用量を最小限に抑え、データへの高速アクセスを保証します。
短所: 下位互換性がなく、このアプリケーションを使用するコードの (かなり面倒な) リファクタリングが必要になります。
返された MongoCursor オブジェクトを、適切に
"_id"マップされた各項目を返す新しい反復子クラスにラップし"id"ます。アプリケーションは、Mongo と通信"id"するときにインバウンド コールを にマップします。"_id"長所: 1. のメモリ効率のほとんどを保持しながら、ほとんどの下位互換性の問題を回避します。
短所：そのようなオブジェクトを実装する方法が完全にわからない、それがきれいにできると確信していない、または私が想像しているのと同じように実際にうまくいくと確信していない. 正しく行うには、他のバックエンドにも同様の反復子ラッパーを実装したいと思います。
iterator_to_array()で説明されているように結果をメモリにロードしMongoCollection.find()、適切な変換を行い、配列を返します。長所: 概念的には 2. より単純で、アプリの残りの部分とうまく連携します。
短所: メモリの点で明らかに悪い選択です。アプリを考えると世界の終わりではありませんが、それでも理想的ではありません.
これらのオプションのいずれかが、この問題に対する特に合理的で堅牢な解決策として際立っていますか? バックエンドにとらわれない方法で主キーを処理するための他の代替案を誰かが提案できますか? 追加のバックエンドは将来的に可能性があるため、他のデータ ストレージ システムに関連する特定の方法の問題または利点も歓迎します。
私は現在2.に傾いていますが、あなたの考えを歓迎します。