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