常に大文字にする必要があるデータベース列があるとします。
ここにいくつかのアイデアがあります：
1) 次の列制約を作成します。col = UPPER(col)
2) 以下を設定する before insert/update 行トリガーを作成します。col = UPPER(col)
通常、データベース データに対する制約が多ければ多いほど良いのですが、トリガーは不可解で悪いものになる可能性があります。コードを書いている開発者は同じ組織に属しているため、彼らが書いたコードは私たちが変更できると仮定します。
どのアプローチを使用しますか?その理由は?
問題のデータは実際には常に大文字であるため、大文字にする必要があります (最初はさまざまなサードパーティによってそのように印刷されています)。この特定のフィールドの大文字と小文字には意味がありません。
列を大文字にする必要がある理由によって異なりますが、一般的には制約を使用します。
データベースに挿入したときにデータを変更するようなものは好きではありません。これは、自分が書いたものと次に読むものとの間に不一致があることを意味します。
ユーザーがテキストを入力した場合は、大文字のバージョンを含む列を追加することを検討してください。このようにして、ユーザーが入力したテキストを常に表示します
これは制約として実装するのが最適です。余分な負荷を回避し、必要なことを行います-データを必要な形式にすることを強制します。
整合性を失わずに変換できるデータはデータベース層で処理する必要があるため、データベースで強制的に変換するのは間違ったアプローチだと思います。ケースが重要でない場合は、そのように処理します。制約はエラーをキャッチするのに役立ちます。
大文字と小文字を区別しないインデックスを追加することは、おそらくより良い解決策です（データベースの大文字と小文字を区別しないインデックスを参照）
あなたが指摘したように、トリガーはしばしば悪い/奇妙になる可能性があるためです（常にではありませんが）。しかし、文字列の大文字と小文字の区別を扱う場合、私はそれを特別なケースとして扱い、途中のすべてのステップで常に修正する傾向があります。そうする具体的な理由があるかどうかはわかりませんが、それが「正しい」と感じているだけです。おそらく、少なくとも私が働いたほとんどの環境では、ビジネス ロジックの観点からFoO常に常に等しいfooためですFOO。
また、この場合、忘れるたびに手首を叩くよりも、「参考までに、サーバーではすべての文字列が大文字で保存されます」と言う方が、開発者にとって負担が少ないようです。「参考までに、価格をDBに入れるたびに消費税が加算されます」というようなものではありません。
データベースの列制約でトリガーを介して何かを実行できる場合は、多くの場合より高速であるため、一般的に好まれます。アプリケーションを介した強制について話している場合は、お勧めしません。ルールを常に適用する必要がある場合は、データベース以外の場所に配置しないでください。コードを記述しているアプリケーション以外のものが、データベース内のデータを変更する可能性があります。データの整合性はデータベースの責任であり、問題を回避するためにコードを所属する場所に保管してください。
別のアプローチも検討します-開発者が値をストアドプロシージャ（または何でも）に渡すことができる「テーブルAPI」を提供し、挿入時に値が大文字であることを保証します（例に従って）。私はこれを制約でバックアップし（クエリの最適化を支援することができます）、テーブルの直接変更権限を削除します-開発者がすべての挿入を大文字にすることを信頼しない場合は、それらを信頼するべきではありませんいずれか常に TAPI を使用します。
または、自動化されたテストの対象範囲を広げて、運用サーバーの余分な負荷を回避します。