0

キャリアの中で、DB でビジネス オブジェクトをモデル化する 2 つの異なる設計を見てきました。

  1. エンティティの ID として常に Long を使用する
  2. できるだけ最適なものを選択してください。

これで、別のサービスからダウンロードできる "Resource" エンティティができました。各リソースには、自然な電子メールが含まれていIDます (電子メールは単なる例であり、使用する必要がある他の状況を想像できますString)。そして、それをデータベースのプライマリ ID として使用したいと考えています。しかし、私の同僚は追加のプロパティを作成したいと考えています - Longid. なぜこの追加のプロパティを作成する必要があるのか​​ わかりません。もちろん、すべてのエンティティが同じ構造を持つため、DB モデルの方が単純ですが、私はStringid を使用することを好みます。

皆さん、どのモデルがはるかに優れていると思いますか?その理由は?

4

4 に答える 4

1

ミハル、

大文字と小文字の区別はデータベースの実装や使用されている照合に依存するため、電子メールやそのような文字データ列は ID として適切な選択ではない場合があります。user@server.com と USER@SERVER.COM で同じ結果を得たいですか? 可能かどうかは、選択したデータベース/OS/照合順序によって異なります。文字データ ベースの ID がある場合、これらの問題をアプリケーションからデータベース管理および照合構成に静かにプッシュします。

これは 1 回限りのアクティビティであり、DB 管理者が設定できるので良いかもしれませんが、多くの場合、異なる OS とデータベースに対して個別の DB スクリプトを維持する必要があります。

私の見解では、これには経験則はなく、状況に応じて最善の判断を下す必要があります。

于 2013-08-02T11:47:08.650 に答える
1

まず第一に、電子メールが「リソース」の一意の自然 ID であると仮定できるかどうかはわかりません。これは、新しいリソースごとに新しい電子メールを作成する必要があり、リソースは電子メールを読み取ることができないことを意味するためです。ケースを知っているので、それは正しいかもしれません。

だから質問に：

影響

  • どのような場合でも、数値 ID の方が検索が高速です。しかし、文字列も非常に高速であるため (適切なインデックスを使用する場合)、ほとんどのアプリケーションには十分かもしれません。
  • 数値 ID は使用するスペースが少なくなります (通常はこれが最も問題になりません)。
  • 異種システムが関係している場合は、通常、文字列 ID が優先されます (例でわかるように、サービスは「リソース」に文字列 ID を提供します)。その理由の 1 つは、デバッグが容易であることです。たとえば、ユーザーはどのオブジェクトが参照されているかを一目で確認できます。もう 1 つの理由は、事実上すべてのシステムで文字列が最も一般的な分母であることです (ただし、エンコーディングの問題は存在します ^^)。
  • データベースで多くの手動ジョブを実行する必要がある場合は、文字列が長くなる傾向があるため、数値をより速く入力できます。
  • 自然な ID を使用する場合、ID が複数の列で構成されているのはかなり一般的なケースです。これにより、オブジェクト リレーショナル マッパーの構成が長くなり、エラーが発生しやすくなるのと同様に、SQL ステートメントが長くなり、エラーが発生しやすくなります。
  • 通常、一意の識別子 (電子メールなど) がありますが、時間の経過とともに変化する可能性があります (人々は結婚します ^^)。そのような場合、いくつかの人工 ID も追加するのが一般的です (両方を持っています)。

あなたの場合、その文字列 ID を使用してこのサービスと通信する以外に選択肢 (?) がないため、少なくともこれも必要です。

ここで、私自身の意見として、デバッグは少し難しくなりますが、開発者として、数値 ID の作業と問題が少なくなると思います。データベース管理者として、列が 1 つしかない場合は、結合が複雑にならないため、列が String であるか Long であるかは関係ありません。文字列が不変である限り、たとえば変更されない限り、問題はありません。変更できる場合は、管理者として頭の痛い問題が発生することは間違いありません (そして、愚かな開発者は少しは気にしません ^^)。時間の経過とともに変更される可能性がある場合は、数値 ID を使用してください。

于 2013-08-02T11:36:38.347 に答える
0

既に述べた議論に加えて、「代理キー」を検索するか、このトピックに関するウィキペディアのページhttp://en.wikipedia.org/wiki/Surrogate_keyにアクセスして、多くの長所と短所をリストすることができます。

于 2013-08-02T11:39:29.247 に答える