レコードが更新されたときのステータス変更を管理するいくつかのストアドプロシージャを変更しています。
たとえば、これら2つのテーブルがある場合
Request(RequestID, StatusID)
Status(StatusID, StatusName)
コード内のステータスの呼び出しを処理するのに最適な方法を決定しようとしています。
使用しますStatusIDかStatusName？
StatusID環境（DEV、PRE、PRODなど）間で一致することは保証されていません。
また、StatusName変更される可能性があり、を変更する必要があるため、コードを変更する必要はありませんStatusName。
によく似た2番目の一意の列を作成できますStatusID。
この列がリージョン間で一致していることを確認しますが、それもそれほどクリーンではなく、反復的なもののようです。
誰かがよりクリーンで簡単な方法を提案できますか？
コードをデータに一致させることの難しさは、2番目の列で部分的にしか処理できません。誰かがアイテムを追加するとき、これはどういう意味ですか？既知の定数を再利用する場合、この列を一意にする必要がない場合はどういう意味ですか？
多くの場合、ユーザーが変更可能なルックアップテーブルがありますが、ステータスの解釈方法を示す他の多くのフラグ（ "IsTreatedAsExpired"、 "IsTreatedAsActive"、または特定のステータスとして扱われるステータスを保持する他のテーブル）に関連付ける必要があります。もの。
最初に、このテーブルで許可したい範囲を理解する必要があると思います。たくさんのコード参照がある場合は、すべてのインストールでコードと同期している自然キーを使用する方がよいでしょう。これを処理する可能性は、移動できないコードに負の数を使用し（ID挿入して新しい移動できないコードを追加する）、シーケンスに正のコードのみを追加させることです。ただし、これは、プログラムがユーザーが入力した拡張機能を処理または使用する方法のセマンティクスには対応していません。
繰り返しになりますが、ここで全範囲を整理せずに言うのは難しいです。
ステータス名を受け入れ、ステータスIDを参照している場合は、ステータスを出力するユーザー定義関数を記述します
select * from resources where statusid = dbo.getStatusId("COMPLETED");
これにより、ステータスIDの解決が常に定義した関数内で行われるようになります
経験則として、id、valueテーブル（ステータス、結果、領域など）がある場合、通常、レコードのニーモニック値である3番目のフィールドを追加し、名前でもIDでもない常にそれを使用します。これで、ニーモニック値は、ビジネス値であり、データベース（IDの場合）や表示方法（説明）に依存しないという意味で、ビジネスキーのようなものになります（まあ、それはビジネスキーです）。あなたのステータステーブルのためにあなたは持っているかもしれません
StatusID,StatusName,StatusMnemo
1 ,COMPLETED ,COM
2 ,REJETED ,REJ
などなど。
また、クエリでは常にstatusIdで参加しますが、StatusMnemoでステータステーブルに対して参加する句を追加します。これは、環境間で独立し、一定に保たれる値です。
また、挿入では、常にstatusidを使用します。
あなたが提供した情報からStatusID、おそらくあなたのキーが自動的に生成され、あなたによって指定されていないために、異なるデータベースで異なる値を持つ可能性があります。StatusIDもしそうなら、明らかに（値を標準化せずに）コードで一貫して使用することは不可能です。StatusNameしたがって、質問は「私のコードに値をハードコーディングすることは許容可能/実用的/望ましいですか？」になります。
明白な答えはイエスです、代替案は何ですか？「準備完了」を表す特定のステータスがあり、それをコードで参照する場合は、ステータスを明確に識別する何かをコードに配置する必要があります。
ある種の2番目のキーを追加した場合（Carlosが提案したように）、自然キーの値を変更するとステータスのIDが変更され、コードの意味が変更されるという同じ基本的な問題が発生します。2番目のキー（）を変更せずに「実際の」自然キー（READY）を変更するRDYと、コードがより混乱し、保守が困難になります。
'定数'または'構成パラメーター'を構成ファイルまたはテーブルに抽出する、または展開時にスクリプトにキー値を挿入するカスタムプリプロセッサーを作成するなど、より複雑なことを行う場合は、ほとんど利益がない場合を除いて、多くの複雑さが追加されます。あなたはそれをする他の正当な理由があります）。私はこのアプローチが使われているのを見てきました、そしてそれは巨大で維持不可能な混乱でした。
実際にStatusNameは、a）別の名前が「より正確」または「見栄えが良い」と誰かが考えている、またはb）それが要件を正しく表していないことに気付いたため、変更される可能性が最も高くなります。a）に時間を費やすことを余儀なくされた場合は、フロントエンドまたはレポートの表示名を変更し、データベースとコードはそのままにしておきます。b）が発生した場合、定義上、現在のデータモデルとコードは不正確であり、とにかく修正し、場合によっては変更する必要があります。また、b）が発生した場合、既存のコードを変更せずに、新しいコードを追加することがよくあります（たとえば、誰かが既存のコードがない新しいプロセスステップを定義したため）。
また、他の人が示唆しているように、開発と展開の慣行を変更することにオープンである場合は、この問題を調べる他の方法もあります。あなたStatusIDはどこでもあなたの価値観を同じにすることができますか？技術的には可能ですが、組織的にそうしない理由は何ですか？StatusName変更管理とコードレビューを通じて、変更の可能性と影響を減らすことができますか？特定の情報をより効果的に取得するために、要件プロセスを改善できますか？
特別な処理が必要なstatusID値がある場合、それらは環境間で同じである必要があります。
PreとDevを通過していないProdで特別な処理が必要なstatusIDを導入するのはなぜですか？
私がよくすることは、100からidenを開始し、特別な処理を必要としない一般的なステータスにそれを使用することです。
次に、DEVは、IDENTITYINSERTONを使用した特別な処理のために100未満のスペースを所有します。
DEVからPREにデプロイする場合は、100未満のレコードを挿入します。