私は現在、約 20 の参照テーブルを含むデータベースを持っています。つまり、製品、資産、デポ、ユーザーなどです。この情報は中央データベースに保存され、外出中のエンジニアの PDA にダウンロードされます。データベース内のすべてのテーブルには、UniqueIdentifier (つまり、GUID) の PK があります。
2 年間の製品開発の後、これらの参照テーブルを編集することは決してなく、編集する必要もないことに気付きました。そのため、主キーとして UniqueIdentifiers を持つ必要はありません。
コレクションを Web サービス経由で PDA に送信する前にすべてのコレクションをシリアル化しているため、実際のシリアル化されたデータは GUID の長さのために巨大です。
とにかく、要点を言えば、テーブルのすべての PK を IDENTITY Ints に変更したいのです。これを行う簡単な方法はありますか?それとも、すべての FK を切断し、一時テーブルを作成してから、データを再マップするソフトウェアを作成する必要がありますか?
前もって感謝します。
PK を参照する FK がある場合、大きな問題が発生します。アプリケーション (PDA) の分散性のために、GUID を使用したと推測しています。おそらく、元の意図は、それらの PDA から新しいデータを追加することであった可能性があります。その場合、GUID が理想的です。欠点は、GUID でインデックスを作成できないことです。
私の提案は、ID int を最初から使用しないことです。まず、FK を無効にします。その PK へのすべての参照 (つまり、同様に FK を持つすべてのテーブル) に対して INT (ID ではない) である新しい列を追加します。次に、GUID ごとに新しい int (次の値) を作成し、それを GUID に対して挿入し、他のテーブルの GUID へのすべての参照を挿入します。次に、int の新しい FK をオンにしてから、PK を新しい int 列にシフトします。最後に、GUID 列を削除してから、インデックスを再構築します。
文字化けしすぎていないことを願っています。
一意のフィールド (またはフィールドのセット) がある限り、PK をそのフィールドに再割り当てできます。つまり、GUID が必要ない場合は、おそらく IDENTITY 代理キーも必要ありません。全体的に最も簡単な方法は、一意の 1 つ以上の null 以外の既存の列で PK を使用することです。
それ以外の場合は、IDENTITY 列を追加して、PK をそれに再割り当てします。(変更されたテーブルを保存すると入力されます。)その後、GUID を使用して列を削除できます。
（あなたのguid列は現在何にも使用されていないため、この議論をしていると思います。別のテーブルのFKであっても、結合する一意の列がある場合は、そこにも必要ありません.)
いずれもあなたの状況に一致しない場合は、詳細を記載して再度投稿してください。これは、ほとんど手間をかけずに行うことができます。
（ところで、テーブルが編集されたとしても、主キーにuniqueidentifiersが必要だと思った理由はわかりません。）
さて、私が理解していないのは、一方では Id 列は必要ないと述べているが、他方では Web サービス経由でそれらを送信していることです。
そのため、最初にクエリを調べて、何がフェッチされているかを確認し、返された結果セットに関して最適化します。
PK を変更するのは大変な作業ですが、"SQL Compare" の助けを借りて行うことができます。