6

HiLo から GUID.comb に切り替えることは可能ですか? 私が知る限り、後者は HiLo の利点、つまり、新しい Id を取得するために DB を呼び出す必要がなく、クライアント側で ID を管理できるという利点と、ID が不足しないという利点を兼ね備えています。

現在、HiLo が生成する Id が大きすぎるため、Int32 (これは Int64 である必要がありますが、これは私の前任者の WTF のようなものです) では十分な大きさではないという問題に直面しています。Int64 に変更することはできますが、これは問題がすぐにではなく後で発生することを意味します。

Id は意味のあるものである必要がないため、GUID への切り替えは理にかなっているようです。しかし、私はそのような切り替えを試みたことがないので、そのようなことがもたらす可能性のある影響を評価するのに誰か助けてくれるかどうか疑問に思っていました.

4

1 に答える 1

6

実際、通常は int64 に切り替えるだけで十分です。さらに 32 ビットを追加していることに注意してください。これにより、id スペースが +/- 2 billion 倍になります。それだけでは十分ではありませんか？

Guid への切り替えに関しては、(ライブ DB を想定して) 以下が含まれます。

  • 新しい pk / fk 列の作成
  • pk 列に新しい値を入力する
  • 古い列に基づいて fk 列を埋める
  • 現在の外部キーと主キーの削除
  • 古い pk / fk 列の削除
  • 新しい主キーと外部キーの作成
  • id プロパティの型とジェネレーターの変更 (これは .net コードを含む唯一の手順です)

とにかく、GUID は「無制限」の ID を提供し、簡単に生成できますが、2 倍の大きさ (128 ビット) であり、手動で操作するのが少し難しいという欠点もあります (つまり、デバッグ時にコピー & ペーストに依存することになります)。

于 2011-02-01T15:05:48.250 に答える