2012-04-14 6 views
0

私はGoogle App Engineを使用しており、ユーザーを保存しています。以前は、私はuserIdフィールドにintを自動インクリメントするMySQLを使用していましたが、GAE autoは、格納する新しいエンティティごとにキーを生成します(g5kZXZ-aGVsbG93b3JsZHIKCxIEVXNlchgNDAなど)が、自動インクリメントID intも自動的に生成します。インデックスとしてクライアントコードに何を保存すればよいですか?

私はクライアントコードでuserIdとして保存する必要がありますか? GAEが生成する長いキーを使用することに利点がありますか、またはパフォーマンスとルックアップの点で同じIDを小さなIDで使用していますか?どちらにも利点がありますか、それとも実質的に違いはありませんか?

編集:申し訳ありませんが、私の質問は十分ではありませんでした。ここに私が求めているものがあります: 長さではありませんが、ルックアップキーを持っているので、それを持っていないことに先立って一歩前進していますか?ユーザーを検索したい場合は、電子メールで検索する必要がありますが、「テーブル」にその行のキーがあるので、これは何か利点がありますか?

+0

[OpenID](https://developers.google.com/accounts/docs/OpenID)などを使用していますか?私は、長期計画が両方のためのものであり、どのように両方がドキュメントを介して使用されるのかを知ることができます。最も長くて変わらないように見えるものを選んでください。 – xQbert

答えて

1

いずれも問題ありません。長い文字列を使用する場合と短い文字列を使用する場合の間にパフォーマンスの違いはありません。

+0

それは長さについてではありませんが、鍵を持っていないと私に前進していますか?ユーザーを検索したい場合は、電子メールで検索する必要がありますが、「テーブル」にその行のキーがあるので、これは何か利点がありますか? – Snowman

+0

データストアのAPIがこのために最適化されているので、おそらくキーを参照したいと思うでしょう。自動インクリメントIDを維持することは、高性能シナリオでは非効率的なので、削除を検討することもできます。 –

+0

大丈夫です。だから私はすでにそれを持っている場合、私はキーで素早くフェッチすることができますか?現在、私は= User.all() \t \t users.filter( "USEREMAIL ="、USEREMAIL) \t \tユーザー= users.get() 'ユーザをやっている' はそれだけで、別のフィルターを通してですか? – Snowman

0

生成されたエンティティIDは、単調に増加する値であるとは限りません。

関連する問題