"Punish"開発者は自動的に修正しますか？トリガーと制約

Question

私は常に大文字である必要があるデータベース列を持っているとしましょう。ここで

は、アイデアのカップルです：

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

2）を設定し、挿入/更新行の前にトリガーを作成します。通常複数の制約col = UPPER(col)

をデータベースデータの方が優れており、トリガーは不思議で悪いことがあります。コードを記述している開発者が同じ組織に属していると仮定して、記述したコードを変更することができます。

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

問題のデータは実際には常に大文字であるため、大文字にする必要があります（元々はさまざまな第三者によってその方法で印刷されています）。この特定のフィールドでは、大文字と小文字の区別はありません。

Answer 1

それはなぜカラムが大文字である必要があるのか​​によって決まりますが、一般的には制約の対象になります。

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

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

Answer 2

自動テストの適用範囲を拡大し、本番サーバーに余分な負荷をかけないようにします。

Answer 3

あなたが指摘したように、トリガーはしばしば悪い/奇妙な（しかし、必ずしもそうではない）ことができるので、私は（1）と言うでしょう。しかし、文字列の大文字と小文字の区別を扱う場合、私はそれを特別なケースとして扱い、その過程のあらゆるステップで常にそれを修正しがちです。私はそうするための具体的な理由がないかどうかはわかりません。ちょうど "感じます"。おそらく、私が少なくともビジネスロジックの観点から取り組んできた環境のほとんどで、は、いつもfooと等しく、常にFOOに等しくなります。

また、このケースでは、「FYI、すべての文字列がサーバー上で大文字で格納されている」と言うのは、開発者にとっては、忘れたたびに手首を叩くことよりも少ないようです。 「FYI、DBに価格を入力するたびに、売上税が追加される」とは言いません。

Answer 4

これは制約として実装するのが最善です。余分な負荷がかからず、必要な処理を行います。

整合性を失うことなく変換できるデータはデータベースレイヤーで処理する必要があるため、データベースで強制的に変換するのは間違ったアプローチだと思います。大文字小文字の区別が重要でない場合は、そのように扱います。制約はエラーを捕捉するのに役立ちます。多分よりよい解決策大文字小文字を区別しないインデックス（参照Database Case Insensitive Index）

Answer 5

を追加

私はまた、別のアプローチを検討する - 開発者は、単にストアドプロシージャ（または任意に値を渡すことができ、「テーブルAPI」を提供します）これは、値が挿入時に大文字になることを保証します（あなたの例による）。私はこれを制約付きでバックアップします（それはクエリの最適化を助けることができます）。そして、テーブルの直接の変更権限を削除します。開発者がすべての挿入を大文字にすることを信用しないと、常にTAPIを使用してください。

Answer 6

トリガーのようにデータベースの列制約で何かできるのは、一般的には高速であることが多いからです。アプリケーションを強制することについて話している場合、私はそれをお勧めしません。ルールを常に適用する必要がある場合、ルールはデータベース内以外の場所には決して配置しないでください。コードを記述しているアプリケーション以外のものは、データベース内のデータを変更することができます。データの整合性はデータベースの責任であり、問​​題を回避するためにコードが所属する場所に保管してください。