テーブル列のリストとそれぞれが持つべきサイズ (varchar 型) を取得し、定義されたサイズになるようにそれらを変更するプロセスがあります。
実際の実装では、リスト内の各列に対してテーブルの変更を直接実行します...
列のサイズが正しいサイズと異なるかどうかを最初に確認してから、テーブルの変更を行うと、実行速度が速くなりますか?
統計的には、チェックするテーブル列が 4000 ほどあり、最大で 20 列を修正する必要があります...
テーブル列のリストとそれぞれが持つべきサイズ (varchar 型) を取得し、定義されたサイズになるようにそれらを変更するプロセスがあります。
実際の実装では、リスト内の各列に対してテーブルの変更を直接実行します...
列のサイズが正しいサイズと異なるかどうかを最初に確認してから、テーブルの変更を行うと、実行速度が速くなりますか?
統計的には、チェックするテーブル列が 4000 ほどあり、最大で 20 列を修正する必要があります...
編集:コメントを反映するには:
どちらが速いかは、列を修正する操作のコストと、変更が必要なテーブル内の列の数によって異なります。たとえば、NULL の 1 つの列を変更するのにそれほど費用はかかりません。ただし、テーブルに大量のデータと多数の列がある場合は、テーブルから新しいテーブルへのコピーを実行する方がよい場合があります。データベースのメトリックに応じてこれを決定します。常に正しい anseer と間違った anseer があるとは限りません。
動的 SQL を作成して、適切なサイズではない列の長さを変更する SQL を作成することができます。これが最速の方法でなければなりません。
何かのようなもの:
SELECT
'some decision logic...' -- substitute values as needed
FROM
INFORMATION_SCHEMA.COLUMNS
WHERE
ISNULL(CHARACTER_MAXIMUM_LENGTH, 5) <> 5
AND DATA_TYPE = 'NVARCHAR'
また、考慮したいメトリック、テーブルサイズ、列のデータサイズ数 (グループ化) などを追加できます。
Sql Server には、このすべてのメタデータが既に格納されており、クエリを実行するだけで済みます。カスタム テーブルでこの情報を複製し、その上でカーソルを実行するのは間違っているようです。あなたが言及していると思う問題は、SQLサーバーのメタデータが常に最新になる一方で、この情報を複製するとデータが古くなる可能性があることです. 簡単にするために、メタデータのビューを作成して、簡単に使用できるようにすることができます。しかし、それは別の質問です。
最後に、alter table の前にチェックを実装しました。alter コマンドを実行する必要があるケースの割合は低く、プロセスは著しく高速に実行されました。