開発者を「罰する」か、それとも自動的に修正するか?トリガーと制約

Question

常に大文字にする必要があるデータベース列があるとします。

以下にいくつかのアイデアを示します。

1) 次の列制約を作成します。 col = UPPER(col)

2) 以下を設定する行の挿入/更新前トリガーを作成します。 col = UPPER(col)

通常、データベース データに対する制約は多ければ多いほど良く、トリガーは不可解で悪質なものになる可能性があります。コードを作成する開発者は同じ組織に所属しているため、開発者が作成したコードは私たちによって変更できると仮定します。

どのアプローチを使用しますか?またその理由は何ですか?

問題のデータは実際には常に大文字であるため、大文字にする必要があります (さまざまなサードパーティによって元々そのように印刷されています)。この特定のフィールドでは、大文字と小文字の区別は意味がありません。

Answer 1

カラムを大文字にする必要がある理由によって異なりますが、一般的には制約を使用します。

データをデータベースに挿入するときにデータを変更するものは好きではありません。これは、私が書いたものと次に読むものとの間に不一致があることを意味します。

ユーザーがテキストを入力した場合、大文字バージョンを含む列を追加することを検討してください。このようにして、ユーザーが入力したテキストを常に表示します

Answer 2

ほとんどの場合、（1）と言います。あなたが指摘したように、トリガーはしばしば悪い/奇妙なものになる可能性があるからです（常にではありませんが）。しかし、文字列の大文字と小文字の区別を扱うとき、私はそれを特別なケースとして扱い、途中のすべてのステップで常に修正する傾向があります。具体的な理由があるかどうかはわかりませんが、「気分」だけです。右。おそらく、私が少なくとも作業したほとんどの環境では、ビジネスロジックの観点から、 FoO は常に foo が常に FOO に等しいためです。

また、この場合、「FYI、すべての文字列はサーバーに大文字で保存されます」と言うことは開発者の負担が少ないようです。忘れるたびに手首をたたくよりも「FYI、DBに価格を挿入するたびに、売上税が追加されます」と言うのとは違います。

Answer 3

これは制約として最適に実装され、余分な負荷を回避し、必要な処理を実行します-データを必要な形式に強制します。

データベースで強制的に変換するのは間違ったアプローチだと思います。完全性を失わずに変換できるデータは、データベース層で処理する必要があるからです。ケースが重要でない場合は、そのように処理します-制約はエラーをキャッチするのに役立ちます。

大文字と小文字を区別しないインデックスを追加する方がよい場合があります（データベースの大文字と小文字を区別しないインデックスを参照）

Answer 4

または自動化されたテストの対象範囲を増やして、運用サーバーへの余分な負荷を回避します。

Answer 5

「Table API」を提供する別のアプローチも検討します。これにより、開発者はストアドプロシージャ（または何でも）に値を渡すだけで、挿入時に値が大文字になります（例ごとに）。これも制約でバックアップし（クエリの最適化を支援することができます）、テーブルに対する直接変更特権を削除します-開発者がすべての挿入を大文字にすることを信頼していない場合は、それらを信頼しないでください常にTAPIを使用します。

Answer 6

データベースの列制約でトリガーとして何かを実行できる場合は、その方が高速であることが多いため、一般に推奨されます。アプリケーションを通じて強制することについて話しているのであれば、それはお勧めしません。ルールを常に適用する必要がある場合、そのルールはデータベース以外の場所にあってはなりません。コードを作成しているアプリケーション以外のものによって、データベース内のデータが変更される可能性があります。データの整合性はデータベースの責任であり、問​​題を避けるためにコードを適切な場所に保管してください。