質問がユーザー ID のハッシュ値を生成する方法だけである場合は、計算列を使用してこの方法で行うことができます (または挿入プロセスの一部としてこの値を生成します)。あなたがHASHBYTES関数について知っているのか、それとも「最高」と言うときに他のどの基準を見ているのか、私にははっきりしません。
DECLARE @foo TABLE
(
userid INT,
hash1 AS HASHBYTES('MD5', CONVERT(VARCHAR(12), userid)),
hash2 AS HASHBYTES('SHA1', CONVERT(VARCHAR(12), userid))
);
INSERT @foo(userid) SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 500;
SELECT userid, hash1, hash2 FROM @foo;
結果:
userid hash1 hash2
------ ---------------------------------- ------------------------------------------
1 0xC4CA4238A0B923820DCC509A6F75849B 0x356A192B7913B04C54574D18C28D46E6395428AB
2 0xC81E728D9D4C2F636F067F89CC14862C 0xDA4B9237BACCCDF19C0760CAB7AEC4A8359010B0
500 0xCEE631121C2EC9232F3A2F028AD5C89B 0xF83A383C0FA81F295D057F8F5ED0BA4610947817
SQL Server 2012 では、上記のいずれかではなく、少なくとも SHA2_256 を強くお勧めします。(使用しているバージョンについて言及するのを忘れていました - 常に役立つ情報です。)
とはいえ、コメントで述べた点に注意を向けたいと思います。ここでの「最善の」解決策は、モデルを修正することです。がオプションの場合employeeNum
、EF はそれが必須または一意であると考えられるべきではありません。また、実際には何らかの識別子でない場合は、リレーションシップで使用されるべきではありません。そもそも関係に適切な属性を使用しているのに、なぜユーザーは と の衝突employeeNum
を気にするのでしょうか?userid
OPの要求に応じて編集
それで、言って何が悪いのUPDATE table SET EmployeeNum = 1000000 + UserID WHERE EmployeeNum IS NULL
ですか?EmployeeNum
が以下にとどまる場合1000000
、衝突がないことが保証され、ハッシュが完全に回避されます。
文字列が含まれている可能性がある場合は、同様のパディングを生成できますがemployeeNum
、これらの恐ろしい列名を促進するのは EF ですか? Num
サフィックス付きの列に数値以外が含まれるのはなぜですか?