database-design - ストアドプロシージャまたはトリガーなしで作業する

Question

過去 18 か月間、複雑なデータベースとクライアントインターフェイスに取り組んできました。このアプリケーションには定期的に新しい機能が追加されており、現在では、拠点や海外を含むすべてのオフィスで、毎日数十人のユーザーに使用されています。これは、REAL データベースを備えた REAL アプリケーションであることを示すためのものです。

これまで、ストアドプロシージャを記述する必要はありませんでしたが、クライアントバージョンと更新されたデータベースモデルの間のマイナーな問題を解決するための一時的な場合を除きます (古いクライアントバージョンでは、新しく作成されたフィールドが適切に更新されず、全員が最新のデータベースモデルをインストールするまで)。バージョン）。

同様に、まだトリガーは必要ありませんでした。実際、SP とトリガーは、システムのもの、またはレプリケーション目的で追加されたものだけです。

開発者がデータベースの最適化はデータベースの正規化に反対しなければならないと考えるとき、SP とトリガーは主にデータベース設計のデフォルトを補うために使用されたり、データベース設計ルールをバイパスしようとしたりするために使用されるという奇妙な感覚があります。

問題は、これらのツールは (開発と保守の両方で) 時間がかかることです。各開発者は、データベースで維持するのに最も「費用がかかる」アイテムであることを念頭に置いて、非常に慎重に使用する必要があります。

データベースにストアドプロシージャやトリガーがまったくないかほとんどないことは、データベースの正規化レベルやコードのメンテナンスコストを示す良い指標であると考えてよいでしょうか?

編集：

トリガーと SP の両方を使用することについて公正な議論を提供した人もいます。しかし、これらのツールは、ほとんどの場合、不適切または過剰な方法で使用されていると私は考え続けています。テーブルフィールド間で複雑な更新を行うため、または合計やその他の集計データを再計算するために、いくつのトリガーが設定されていますか? 問題を報告するための一時テーブルを作成するために使用される SP の数は? これらは、開発者がこれらのツールを使用する多くの状況の 2 つであり、これは通常、データベースの設計/正規化の欠陥を示していると思います。

SP とトリガーの使用を厳密に管理する必要があることを認めている人もいます。私も必要だと思います。

私は、他のデータベースで働いているこれらすべての SQL ギークが私たちを見下し、友人たちに「ほら、彼らは SP やトリガーさえ使っていない!ハハ!」と言って、支持する議論を見つけようとしていると告白しなければなりません

score 12 · Accepted Answer

ストアドプロシージャとトリガーはツールであり、データベース管理システム内で使用するための非常に特殊なツールです。

トリガーには、履歴テーブル (各行がプライマリテーブルの過去の期間を表す)のメンテナンスを大幅に簡素化することから、データウェアハウスへの ETL の要求をキューに入れること (特定の RDBMS によって異なります) まで、さまざまな用途があります。

ストアドプロシージャも、アプリケーションから呼び出されるか、SQL コマンドラインツールから呼び出されるかにかかわらず、その役割を果たします。

ストアドプロシージャまたはトリガーを含めることは、正規化または「データベース設計のデフォルト」とはまったく関係ありません。アプリケーションでの使用は、多くの場合、アプリケーションの他の要件、スケーラビリティ、信頼性、レプリケーション、またはこれらのツールを使用することで最も効果的に満たすことができるその他の要件に直接関連しています。

必要がない場合は、使用しないでください。ただし、トリガーやストアドプロシージャが存在するからといって、設計が不十分であるとは限りません。

score 12 · Accepted Answer

データベースにストアドプロシージャやトリガーがまったくないかほとんどないことは、データベースの正規化レベルやコードのメンテナンスコストを示す良い指標であると考えてよいでしょうか?

いいえ、あなたがすることはできません。

正規化とストアドプロシージャは、互いに完全に分離されています。

SP についての私の見解は、データベースとそれを使用する人々の間の抽象化の層です。

直接の CRUD 操作の代わりに SP を使用するように強制すると、テーブルを壊さずにテーブルのデザインを簡単に変更できます。

score 5 · Accepted Answer

ストアドプロシージャに関しては、セキュリティの問題を忘れないようにしましょう。アプリケーションがインライン SQL を実行できるようにするには、ユーザーアカウントにすべてのテーブルへの直接の読み取り、挿入、更新、および削除アクセスが必要であることを意味します。侵害が発生した場合、データベースが公開されます。

トリガーにはそれぞれの場所があります。特に、(たとえば) SOX 要件を知っているかどうかわからない多くのデータベース開発者がいる環境では、予算情報の変更履歴を保持しています。

score 5 · Accepted Answer

コード内に大量のインライン SQL があり、バグが含まれていることに遭遇することほど嫌いなことはありません。少なくとも Stored Proc を使用すると、構文をチェックしたり、実行して問題がどこにあるかを確認したりできます。実行計画が保存されているため、DB でクエリを実行するよりも高速であることは言うまでもありません。私は長い間、DB コードは DB に属しているという意見を持っていましたが、それは単なる私の意見です。

そして、トリガーには用途があります。それらは常に最高のものではありませんが、確かに理由があります。

score 2 · Accepted Answer

データベースからデータを取得するにはどうすればよいですか? SQL 文字列を作成して実行しますか? その場合、エントリがデータベースを破壊しないことをどのように検証しますか? ストアドプロシージャは、テキストがコマンドとしてではなくテキストとしてサーバーによって処理されるという事実だけで、このリスクを大幅に軽減するのに役立ちます。

ストアドプロシージャは通常、データベースに対して SQL 文字列を実行するよりもはるかに高速に動作します。また、ストアドプロシージャですべて実行できるため、さまざまな情報のグループに対してさまざまな選択を記述する必要がないことも意味します。プログラムからデータベースを抽象化する機能も、何度か取り上げられてきた利点です。

最後に、私は実際にはデータベース監査用のトリガーのみを使用してきました (SQL2005 より前には組み込みの監査機能はありませんでした)。これは、各変更の前の値と新しい値でテーブルを更新します。

正規化と最適化は、ストアドプロシージャやトリガーとは何の関係もありません。正規化と最適化は、データベースを抽象化する必要がある量に影響を与える可能性がありますが、データベースを変更するたびにコードをリファクタリングしなければならないことは、ストアドプロシージャを使用するよりもはるかに悪いと思います。

score 2 · Accepted Answer

「テーブルフィールド間で複雑な更新を行うため、または合計やその他の集計データを再計算するために、いくつのトリガーが設定されていますか?」

トリガーを使用してビジネスルールに基づいて複雑な更新を行うことは、問題ではありません。これは好ましい方法です。データの整合性を維持するには、すべてのビジネスルールをデータベースレベルで実施する必要があります。データベース内のデータに影響を与える方法は、ユーザーインターフェイス以外にもあります。使用する方法に関係なく、ビジネスルールを適用する必要があります。そうすれば、インポートされたデータはルールに従う必要があり、新しい機能はルールに従う必要があります (ルールがあることを覚えて、それを適用するために構築した機能を見つける必要はありません)。人々はクエリツールからデータを一括更新します (すべての価格を10％上げると思います）、ルールに従う必要があります。

別のレポートデータベースがない場合は、レポートの速度を上げるために合計の再計算が行われる傾向があります。数百万のレコードに対して合計を計算する必要があるため、実行に数時間かかる財務部門の四半期レポートを実行するときに、データベース全体の速度を落としたり、ロックしたりしますか? それとも、データを変更するたびに 1 秒長くかかるようにしますか? これは通常、データベースが大きくなり、別のレポートデータベースを用意するコストが正当化されるほど大きくなる前にのみ使用される方法です。したがって、これは一時的な手段ですが、元の設計から新しい設計に移行する際にビジネスを継続するために非常に必要な手段です (OLAP を構築するにはかなりの時間と異なるスキルが必要です)。データベース）。

score 2 · Accepted Answer

いいえ。ストアドプロシージャとトリガーはさまざまな方法で使用されます。状況や開発者などによって異なります。たとえば、ストアドプロシージャはセキュリティメカニズムとしてよく使用されます。

トリガーを使用するのに適していると私が見た唯一の場所は、データベースをリファクタリングするときです。だから多分あなたはその点で何かに取り組んでいます. しかし、他の人々はそれらを別の方法で使用するかもしれません。

score 1 · Accepted Answer

SPが絶対に必要な1つの例を次に示します。ユーザーインターフェイスは、アプリケーション全体のごく一部にすぎません。そして、プロセス全体がユーザーから独立して発生する場合。たとえば、私は多くの異なるソースからの多くのデータ処理を含むプロジェクトに取り組んでいます。したがって、これらのファイルを受け取ったら、スクリプトシェルを実行するだけで、SPを起動して、ファイルからすべてのデータをインポートし、チェックし、操作するなどの操作を行うことができます。この同じSPは、データ処理クエリ全体を再度書き直す必要なしに、ユーザーインターフェイスからユーザーが使用することもできます。

もちろん、これらの処理クエリが単純なSELECTである場合は、SPの必要性について議論できますが、数十のテーブルを更新し、フィールドを計算し、データをパージし、データをクリーンアップする必要がある場合、SPは祝福されます。そして、それは私たちのデータベースが標準化されていないことを意味するわけではありませんが、毎日何十億ものデータを処理する場合、すべてが単純になるわけではありません。

score 1 · Accepted Answer

現在、約 8 つ以上の異なるバージョン (API とフロントエンドとバックエンドの多くのバージョン) が浮かんでいるため、これはトリガーの良い例だと思います。何かを処理する方法を変更したい場合、8 つ以上の異なるコードベース (さまざまなレベルのスパゲッティコーディングを使用) でまったく同じ変更を行うよりも、トリガー内にあればはるかに簡単だったでしょう。不適切な名前の変数)。

score 0 · Accepted Answer

7 つの異なるアプリがすべてユーザーデータベースと通信している場合、7 つの異なるアプリケーションが独自に INSERT ステートメントを作成するよりも、"createUser" というストアドプロシージャを使用する方が理にかなっているでしょうか?

そして今、新しいアプリはこのデータベースにユーザーを追加する必要がありますが、新しい要件があり、追加する必要がある新しいフィールドがあります。そのデフォルト値は、まったく異なるサードパーティアプリケーションのデータベースに格納されている値から入力されます。

ここで、INSERT ステートメントを作成しながら、これら 7 つのアプリと新しいアプリを変更して、サードパーティのアプリと通信して値を取得します。

または、ユーザーデータベースの createUser プロシージャを変更して、サードパーティのデータベースからデフォルト値としてデータを検索することもできます。これにより、他のプログラムを変更して再デプロイする必要がなくなります。なぜなら、他のプログラムはその値をあまり気にしないからです...まだ。

または、ユーザーテーブルが更新されたときにトリガーをユーザーデータベースに追加して、サードパーティデータベースからその値を取得することもできます。

ストアドプロシージャには、コンパイルできるという利点もあるため、通常のステートメントよりも高速です。

ストアドプロシージャは、1 つの複雑な SQL ステートメントを複数の単純なステートメントに分割して、クエリの実行速度を上げることもできます。

データ要件が変更された場合、何千ものアプリケーションのインストールを更新するよりも、ストアドプロシージャを変更する方がはるかに簡単です。

私の $.02

ps。私は何年もの間、アプリケーションに 1 行も SQL を書いていません。それはすべてストアドプロシージャで行われます。単純な選択、挿入、更新、複雑なレポート、またはアプリケーション内の事実上単一のオブジェクトであるが、データベース内の 7 つの異なるテーブルにまたがって保存される更新などです。

database-design - ストアド プロシージャまたはトリガーなしで作業する

10 に答える 10

Related

Reference

database-design - ストアドプロシージャまたはトリガーなしで作業する