ネイティブの UUID/GUID データ型を持たないデータベースに UUID/GUID を格納するための最も効率的なデータ型は何ですか? 2 BIGINT?
また、GUID からその型に変換する最も効率的なコード (C# を推奨) は何でしょうか?
ありがとう。
ネイティブの UUID/GUID データ型を持たないデータベースに UUID/GUID を格納するための最も効率的なデータ型は何ですか? 2 BIGINT?
また、GUID からその型に変換する最も効率的なコード (C# を推奨) は何でしょうか?
ありがとう。
使用しているデータベースを知らずに何が最も効率的かを言うのは困難です。
私の最初の傾向は、binary(16)
列を使用することです。
C# でその値を使用する場合、System.Guid
型には、配列を受け入れるコンストラクターと、バイト配列を返すbyte[]
メソッドがあります。ToByteArray()
私の経験では、2つの整数に分割されたUUIDは、charフィールドを使用するよりも効率的です。ただし、DBが異なれば反応も異なります。照合はそこでも違いを生む可能性があります。そうは言っても、通常、アプリケーション全体ではるかに大きなパフォーマンスの「罪」があり、これが多くのアプリケーションにとってどちらの方法でも大きな問題になるとは思いません。アプリのこの部分がどれだけ忙しくなるかに基づいて、自分自身を判断する必要がありますか?おそらくUUIDによる絶対最速のクエリが必要ですか?600nsと400nsの時間差は大きいですか?
dbを使用して手動でSQLを実行することが多い場合は、挿入を行う必要があり、dbのデフォルトがない場合に、別のフィールドからのUUIDを含むキーを使用することは悪臭を放ちます。それはcharsの問題でもあります。
データベース抽象化レイヤーがある場合は、複数のテーブルフィールドを組み合わせてUUIDを取得することは大したことではありません。
.NET GUID クラスを見ると、GUID を初期化する方法がいくつかあります。
Guid(Int32, Int16, Int16, Byte, Byte, Byte, Byte, Byte, Byte, Byte, Byte) Guid(文字列)
理論的には、整数をデータベースに格納する方が効率的かもしれませんが (実際にはビット シフトを使用して 4 つの 32 ビット整数を格納できますが、毎回ロードおよび保存するときにこれを計算する必要があります。さらに、データベースで4つのフィールドが必要になります..効率が低下することになると思います。
デバッグ/テストの目的でこれをデータベースで直接読み取ることは不可能であることを付け加えてください。文字列を保存するのが最善であることは間違いありません。これはわずか 32 文字のフィールド (ダッシュを含めると 36 文字) であり、変換は非常に簡単です。ガイド。ToString()と 新しい Guid(stringValue);