1

列の型を text/ntext から varchar(max)/nvarchar(max) に変更することに懸念はありますか?

それは何かを壊すことができますか？例、ntext パラメーターを持つ sprocs...

4

1 に答える 1

6

たとえば、現在次の関数を使用している場合など、いくつかの懸念事項があります。

コードベースの検索を実行して、これらを特定することをお勧めします。アドホックSQLを使用している場合は、アプリケーションやソース管理をgrepするか、次を使用してストアドプロシージャなどを検索します。

SELECT OBJECT_SCHEMA_NAME([object_id]), OBJECT_NAME([object_id])
  FROM sys.sql_modules
  WHERE [definition] LIKE '%WRITETEXT%'
     OR [definition] LIKE '%READTEXT%'
     OR [definition] LIKE '%UPDATETEXT%'
     OR [definition] LIKE '%TEXTPTR%';

TEXT以下を使用して、これらのパラメーター（との両方を含めたNTEXT）を使用してプロシージャと関数を識別することもできます。

SELECT OBJECT_SCHEMA_NAME([object_id]), OBJECT_NAME([object_id]), name
  FROM sys.parameters
  WHERE system_type_id IN (35, 99);

そして、以下を使用するこれらの列タイプのテーブル/ビュー/TVF

SELECT OBJECT_SCHEMA_NAME([object_id]), OBJECT_NAME([object_id]), name
  FROM sys.columns
  WHERE system_type_id IN (35, 99);

または、すべてのAPI /プロバイダーについてはわかりませんが、ntextパラメーターの交換に問題があるnvarchar場合があります（また、コードの一部を明示的に変更して、最大長-1を指定する必要がある場合があります）。これらのタイプがまだ流行していたとき（〜1999）にインターフェースコードに取り組んでから長い時間が経ちましたので、そこで記憶がぼんやりしていることをお詫びします。

ストアドプロシージャが引き続きNTEXTパラメータを取得する場合は、重大な変更を加える必要はありませんが、それらを長期間そのままにしておくことは望ましくありません。

ほとんどの場合、パフォーマンスの向上、データ操作の容易化、および新しいタイプとの全体的な互換性の向上を体験する必要があります。将来を保証することを気にしないでください！

于 2012-07-06T00:36:38.370 に答える