2011-10-18 4 views
2

データベースのmd5ハッシュカラムにインデックスを置く必要があります。私はmd5列の検索を行います。私はCHAR(32)としてハッシュを格納しようとしていましたが、バイナリカラムオプションも見ました。 md5ハッシュをバイナリ列またはchar(32)に格納する方が良いでしょうか。エンティティにLinqを使用してバイナリ列をクエリできますか?もしそうなら、私はこれについてどうやって行くのですか?Linq:データベースにMD5ハッシュカラムを格納する方法

+0

技術的には、バイト配列を16進化する代わりに、Base64 it( 'Convert.ToBase64String(bytes)')と24バイトの文字列を得ることができます。 – xanatos

答えて

5

SQLServerまたは128ビットのGUIDタイプをサポートする他のサーバーを使用している場合は、GUIDタイプを使用してMD5値を表現できます。

MD5は16バイト(128ビット)なので、簡単にGUIDに変換できます。 C#でこれを行うには、Guid構造体を使用したり、簡単な変換ルーチンを手作業で書くことができます。

ガイドの形式はxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxです(xは16進文字ですが、128ビットの整数として内部的に格納されるため、スペースがほとんどなく、非常に高速です)。クエリ!

GUIDSはcharまたはバイナリよりもはるかに優れていますが、固定サイズであり、非常に高速で低消費電力であるため、より多くのビットが必要な場合はINTの代わりにキー\インデックスとしてよく使用されます。

+0

質問はSQL Server 2008でタグ付けされているので、はい。 :) – bzlm

+0

Lolはい:)私はより一般的な答えをしようとしました:抽象化は常に良いことです:D –

+0

ワウ..これは非常に良いアイデアです。私はこれを実装します。 – Luke101

0

インデックスが同じであれば、どのタイプを選択しても問題はありませんが、その違いはストレージにあります。バイナリ型はおそらく小さくなりますが、char型は値を整数としてエンコードします。本当にその日の終わりには、バイナリをより寛容にするためにcharを使用します。だから、何百万ものこれらのものを保管していない限り、大きな違いはありません。

LINQについてはわかりませんが、私はあなたができると確信しています。フィールドの代わりにフィールドになるでしょう。それは私がcharに行くだろう他の理由です、それはlinqを扱いやすくなります。

+0

"フィールドの代わりに"フィールド? – bzlm

+0

ああ、それは私の返答の一部を取り除いた、まだスタックオーバーフローの新しい。そこにあるはずのものは、テンプレートクラスのような記号よりも優れています。データセットのlinqのフィールドを参照するときは、データの元の列の型を指定します。それはバイナリではなくcharです。 –

+0

フィールド()の代わりに、フィールド()のような意味ですか?それがここでは関係ないかどうかはわかりません。それはEF(L2E)で、古いADO 2.0のLinqからDataSetへのものではありません。 :) – bzlm

0

実際にコード内のハッシュをどのように表現するかによって異なります。バイト配列の場合は、バイナリDB型を使用してください。それが文字列の場合は、それを使用します。どちらの方法でも、それはあるレベルのすべてのバイナリデータです。データを表示するときにコンピュータがそれを解釈する方法だけです。

関連する問題