私が言ったように、私は現在、何らかの方法でデータを永続化する必要があるプロジェクトに取り組んでいますが、それを永続的に行う必要はありません。つまり、SQL DB などを作成したくありません。そこで、空のローカル データベース (エンティティ データ モデル) を使用してそれを行うことを考え、次に示すように、テーブルとして機能するいくつかのエンティティを作成します。
マークされた変数を Guid 型として宣言しました。実際のところ、私はGuidを使って数回しか作業をしていませんでした。それらが何の目的で使用されているかをよく理解しているかどうかはわかりませんが、オブジェクトの Id として適しているようです。Microsoft の定義を見ると、「そのような識別子は重複する可能性が非常に低い」とあります。これで、今回は十分です。私は、独自の Id を int 値として作成するこのオブジェクトを使用することを好み、新しい行を挿入する必要があるたびにそれを増やす必要があります。
このような問題に直面しなければなりませんでしたか？（私の英語でごめんなさい）
ええ、GUID は一意の識別子には問題ありません。それが設計された目的です。衝突の可能性は信じられないほど低いです。
生成された各 GUID が一意であるとは限りませんが、一意のキーの総数 (2^128 または 3.4×10^38) が非常に多いため、同じ数が 2 回生成される確率は非常に低くなります。たとえば、約 5×10^22 個の星を含む観測可能な宇宙を考えてみましょう。すべての星は、6.8×10^15 個の普遍的に一意の GUID を持つことができます。
また、次の質問を見てください。
これは何時間も実行されます。1 GHz でループすると仮定すると (そうはなりません。それよりもずっと遅くなります)、10790283070806014188970 年間実行されます。これは、宇宙の年齢の約 830 億倍の長さです。
ムーアの法則が成り立つと仮定すると、このプログラムを実行せずに数百年待ってから、数十億倍高速なコンピューターで実行する方がはるかに高速です。実際、CPU 速度が 2 倍になるよりも実行に時間がかかるプログラム (約 18 か月) は、CPU 速度が向上するまで待ってから新しい CPU を購入してから実行すると、より早く完了します (ただし、CPU 速度が 2 倍になるように記述しない限り)。新しいハードウェアで一時停止および再開できます)。
整数を識別子として使用する場合は、同じ ID を使用して 2 つのスレッドが同時に挿入を実行するのを防ぐために、シングルトンが配置されていることを確認する必要があります。それ以外の場合は、一意でない ID を持つレコードを挿入するときに発生する例外を処理する必要があります。
識別子に GUID を使用できます。これにはいくつかの利点といくつかの欠点があります。最も顕著なのは、(メイン) データベースから切断されている間に ID をオブジェクトに割り当てる必要がある場合、おそらくこれが最も簡単な方法です。欠点として、GUID は (int と比較して) 読み取りと編集が困難です。
Id に int フィールドを使用するのは実際には非常に簡単で、自分でインクリメントする作業を行う必要はありません。db スキーマでフィールドを「Identity」として宣言するだけで、データベースがそれをインクリメントします。