8

ユーザーIDの数値比較を行う必要がある場合、次のようにする必要があります:

int numeric_user_id = Integer.valueOf("1234343");

それとも、それを長いものにするか、整数のままにする方が良いですか?

ありがとう！

4

6 に答える 6

9

一意の識別子は、特別な意味を持たないようにする必要があります。これまで。UUIDまたはGUIDタイプは、エンティティ識別子専用に設計されているため、それらに意味的な意味を推測することはありません。これにより、UUIDまたはGUIDが不透明になります。

多くの実用的な利点の1つは、データを別のデータベースにインポートおよびエクスポートするときに衝突しないことです。開発、qa、本番、またはクラスターで使用する場合。単純な古い番号、特に自動インクリメント番号を使用する場合、各データベースには同じ番号に対して異なるユーザーが存在し、重複やその他の不正なデータが異なるシステムに忍び寄るのを防ぐことはほぼ不可能です。UUID / GUIDソリューションは、この種の問題を完全に回避します。

ID以外の目的でIDを使用しない理由はたくさんあります。30000人を超えるベータユーザーがいる場合はどうなりますか、ベータユーザープログラムから一部のユーザーを追い出したい場合はどうなりますか？

ベータユーザーの識別などのビジネスロジックにIDを使用する場合は、そのIDを使用せず、別の属性フラグを使用してそれらを識別します。ブールフラグ、列挙型、またはその他のフラグを設定したり、ベータユーザーであるという事実と、ベータプログラムに参加したときのフラグを組み合わせたりすることもnullable timestampできますが、最終的には懸念を漏らすことによる柔軟性の低下。ただし、場合によっては適切な場合もあります。

public interface Identifiable {

    public UUID getUUID();
}

public interface BetaUser extends Identifiable {

    public boolean isBetaUser();
    public Date    joinedBetaProgramOn();
}

int、、longおよびその他のタイプは、数学numberにのみ使用する必要があります。数学的な懸念とは関係のないID管理やビジネスロジック用ではありません。

システムのユーザーを取得したい場合nthは、参加日で並べ替え、リストからインデックスを取得します

于 2013-01-06T16:28:06.733 に答える
3

null 値を許可するという理由だけで、Long (プリミティブではなくオブジェクト) を使用することをお勧めします。一時的なユーザー オブジェクト (コピー、クローン作成など) を操作するときに、これが必要になる場合があります。

ただし、それらをデータベースに永続化する場合は、userId 列を非 null にします (できれば、それを主キーにします)。

将来のオーバーフローを心配する必要がないように、Integer ではなく Long を使用してください。

userId を比較したり、論理的な目的 (誰がベータ ユーザーであるかを判断するなど) に使用したりしないでください。不透明な識別子として保持してください。誰がベータ ユーザーかを知る必要がある場合は、それを追跡するためのデータ (accountType など) を導入します。

他の人が述べたように、UUID はもう 1 つの完全に受け入れられる方法であり、その性質上 (完全ではありませんが) かなり不透明であるというボーナスがあり、「ユーザー ID を解釈しない」ルールをほぼ強制します。

于 2013-01-06T16:16:23.027 に答える
1

この場合、最良の方法は、整数の代わりに単独のプリミティブ型を使用することです。

于 2013-01-06T16:12:50.053 に答える
1

私はそれを長いプリミティブに入れてください。その理由は、null にしたくないと仮定すると、「getUserId()」メソッドが null ユーザー ID を返し、エラーがキャッチされないという偶発的な状況が発生することは決してないからです。

long 対 long または Integer に格納すると、システムはすぐに実行時エラーとして検出します。

実際のオブジェクトに格納すると、Long のように null になる場合があります。これがエラーである場合、コードは後で予測不能な方法で失敗する可能性があり、損害を与える可能性があります。できるだけ早くエラーを検出することをお勧めします。

null の可能性があり、実際のオブジェクトを使用する場合は、null ケースを処理するコードを必ず記述してください。

int と long については、int のサイズを超えるかどうかに基づいて決定する必要があります。

これはまた、あなたの唯一の選択肢が通常の数値型であることを前提としています。おそらく、そのような ID により適した別のデータ構造があり、

于 2013-01-06T15:52:54.810 に答える
0

intを提唱する答えがまだないのは奇妙です。すべてのアプリケーションの 99.99% で十分な、自動インクリメントされた主キーとして。さらに、ユーザー リファレンスは多数 (作成者、最終編集者など) あるため、長い時間ではなく、少し節約できると便利です。

ユーザーメモやその他の歴史的なアイテムなどがある場合、Long は主キーとして使用されます。

ルール: Java ソースとデータベースへの変更は簡単なので、やがてintから始めます。

于 2013-01-06T17:09:07.787 に答える