9

整数の主キーを持ついくつかの参照テーブルを使用します。ここで、intをGUIDに変更して、すべての参照をそのままにします。それを行う最も簡単な方法は何ですか？

ありがとうございました！

添加

私は一般的なプロセスを理解しているので、新しいGUID列に入力する方法など、より詳細なアドバイスが必要です。デフォルト値のnewid（）を使用するのは正しいですが、既存の行はどうでしょうか。

4

7 に答える 7

13
  • マスターテーブルにGUID値の新しい列を作成します。uniqueidentifierデータ型を使用し、newid（）のデフォルトでnullにならないようにして、既存のすべての行にデータが入力されるようにします。
  • 子テーブルに新しいuniqueidentifier列を作成します。
  • updateステートメントを実行して、既存のint関係を使用してギルド関係を構築し、エンティティを参照します。
  • 元のint列を削除します。

さらに、GUIDはint ID列のようにシーケンシャルではないため、データ/インデックスページにスペースを残します（fillfactor <100を指定）。つまり、挿入はデータ範囲内のどこにあってもかまいません。ページが100％いっぱいになると、ページ分割が発生します。

于 2008-09-26T07:48:08.883 に答える
6

第一に：親愛なる神様なぜ？！？！？

次に、最初にすべてのテーブルにGUID列を追加してから、int値に基づいてテーブルにデータを入力する必要があります。完了したら、GUIDを主キー/外部キーに設定してからint列を削除できます。

値を更新するには、次のようにします

  1. 主キーテーブルに新しいGUIDを設定します
  2. これを実行します：

。

UPDATE foreignTable f
SET f.guidCol = p.guidCol
FROM primaryTable p
WHERE p.intCol = f.intCol
于 2008-09-26T07:42:42.657 に答える
3

これは、分散コンピューティング モデルを実装するシステムに関係します。システムに情報を永続化するときにシステムが主キーを知る必要がある場合、ONEハンドラによって維持される自動インクリメント主キーを使用すると、システムの速度が低下します。代わりに、主キーを作成するための GUID ジェネレーターのようなメカニズムが必要です (主キーの真の特徴はその一意性にあることに注意してください)。そのため、複数のサービスでスケールアップし、それぞれが互いに独立して主キーを作成できます。

私は以前にこれを行う疑わしい特権を持っていました.基本的に私がしなければならなかったのは、いまいましいデータベース全体をXMLにエクスポートすることでした. 次に、java.util.Random の nextLong() 関数を使用して主キーを新しい GUID キーに置き換える Java アプリケーションを用意しました。その後、すべてをデータベースにインポートしました。

もちろん、XML ファイルを初めてインポートしようとしたときに、主キー フィールドの自動番号付け機能をオフにするのを忘れていたので、間違いから学んでください。もっと良い方法があると確信していますが、これは速くて汚い方法でした...そしてうまくいきました。ご参考までに、このプロジェクトはアプリケーションの規模を拡大することでした。

于 2008-09-26T08:18:29.060 に答える
2

ええ、私はグレンと一緒です...私は彼がそれを投稿する前に実際に同じものを投稿することを躊躇していました....

GUIDとは別に自動インクリメントint主キーが必要ないのはなぜですか？はるかに柔軟性があり、GUID列にインデックスを付けるだけで、クエリのパフォーマンスが向上します...

柔軟性に関しては、他のユニークで主キーに値するアイテムが変更される可能性があるため、IDを自動インクリメントintとして保持するのが好きです。

柔軟性の良い例は、ユーザー名を主キーとして使用する場合です。それらがユニークであっても、それらを変更できるのは素晴らしいことです。ユーザーがユーザー名としてメールアドレスを使用した場合はどうなりますか？ユーザー名を変更して、すべてのクエリに影響を与えないようにすることは大きなプラスです。GUIDについても同じことが言えると思います。

于 2008-09-26T07:46:03.163 に答える
0

手動でやらなきゃいけないと思います。または、そのためのユーティリティを作成することもできます。シナリオは次のようになります。

  • 「int」PK/FK列を新しい「guid」列と複製します。
  • 「GUID」PK列の新しい値を生成します。
  • 「guid」FK列の値を指定された値で更新します（「int」PKを介してレコードを検索します）。
  • 「int」PK/FK列を持つ参照（リレーション）を削除します。
  • 「guid」PK/FK列を使用して同様の参照（リレーション）を作成します。
  • 「int」PK/FK列を削除します。
于 2008-09-26T07:47:48.383 に答える
0

とても良い選択です。アプリケーションの 1 つで long から UUID に切り替えましたが、後悔していません。MS SQL Server を使用している場合、標準に含まれています (私は postgresql を使用しており、8.3 以降の標準にのみ含まれています)。

Glenn Slavenが述べたように、現在のレコードにあるキーから UUID を再作成できます。ただし、それらは一意ではないことに注意してください。ただし、そのようにして、関係をそのまま維持するのは簡単です。移動後に作成する新しいレコードは一意になります。

于 2008-09-26T08:45:42.223 に答える
0

それをしないでください！GUID の使用を開始しましたが、今では PK としての INT への移行がほぼ完了しています。ログの目的で (および、「交渉可能なリレーショナル整合性」の一部のテーブルのために ;)) GUID を保持していますが、int を使用することによる速度の向上は驚異的です。

これは、テーブルの行数が数百万を超えたときに初めて明らかになりました。

私たちの最大の愚かさは、(シーケンシャル) ログ テーブルの PK として NEWID() を使用していたことです。

于 2008-09-26T08:49:21.980 に答える