ストアド プロシージャ、安全で高速なストアド プロシージャに代わるものはありますか。私は休止状態だけを知っています。そのような技術は他にありますか?
8 に答える
ストアド プロシージャは、データベース上で実行されるコード (SQL) を配置する場所なので、意味する質問を理解しています
「データベースで実行するコードをパッケージ化する他の方法はありますか?」
いくつかの答えがあります:
- ストアド プロシージャとまったく同じものは他にありませんが、検討できる代替手段があります。
- すべての SQL をクライアント コード (Java など) 内の文字列として記述できます。
- ただし、これにはさまざまな問題 (カプセル化の損失、緊密な結合 -> より困難なメンテナンス) があり、良い考えではありません。
- クライアント ロジックとデータベースの間にレイヤーを挿入する NHibernate などの ORM を使用できます。ORM は、データベースで実行する SQL を生成します。ORM を使用すると、ストアド プロシージャよりも複雑なビジネス ロジックを表現するのが難しくなります (スイープ一般化!)。
- 中途半端な家のようなものは、独自のデータ アクセス レイヤー (DAL) を Java (または使用しているすべての水) で定義し、それをクライアント コードの本体から分離しておくことです (分離したクラス / 名前空間 / など)。クライアントが DAL を呼び出すと、DAL はこれらを解釈して SQL をデータベースに送信し、データベースからの結果をクライアントに返します。
はい。動的SQLを使用できますが、個人的にはストアドプロシージャの方が好きです。
1) MS SQL Server を使用している場合、ストアド プロシージャを単純な動的 SQL よりも高速に実行できるクエリ プランが生成されます。
2) ストアド プロシージャのバグを修正することは、特にアプリケーションがそのプロシージャをいくつかの場所で呼び出す場合に、より簡単かつ効果的になる可能性があります。
3) 組み込みの SQL ファイルやアプリケーション構成ファイルではなく、データベース ロジックをデータベースにカプセル化するのが良いと思います。
4) データベースにストアド プロシージャを作成すると、SQL Server は設計時にいくつかの構文と検証チェックを行うことができます。
Hibernate は、オブジェクト/リレーショナル永続化サービスです。
ストアド プロシージャは、リレーショナル データベース システム内のサブルーチンです。
同じことではありません。
Hibernate の代わりが必要な場合は、iBatis for Springを確認できます。
ストアド プロシージャと同じくらい安全かつ高速に動的 SQL を実行できますが、多少の作業が必要です。もちろん、ストアド プロシージャを安全かつ高速にするには、ある程度の作業が必要です。
ストアド プロシージャは、リレーショナル データベース システムにアクセスするアプリケーションで使用できるサブルーチンです。ストアド プロシージャ (proc、sproc、StoPro、または SP と呼ばれることもあります) は、実際にはデータベースのデータ ディクショナリに格納されます。
ストアド プロシージャの一般的な用途には、データ検証 (データベースに統合) やアクセス制御メカニズムなどがあります。さらに、ストアド プロシージャは、元々アプリケーションに実装されていたロジックを統合および一元化するために使用されます。複数の SQL ステートメントの実行を必要とする可能性のある大規模または複雑な処理はストアド プロシージャに移動され、すべてのアプリケーションはプロシージャのみを呼び出します。
ストアド プロシージャは、ユーザー定義関数 (UDF) に似ています。主な違いは、UDF は SQL ステートメント内の他の式と同じように使用できるのに対し、ストアド プロシージャは CALL ステートメントを使用して呼び出す必要があることです。
この記事を読んで、質問を再構成する必要があると思います。Hibernate はストアド プロシージャとは関係ありません。
代替手段を探している理由を説明すると、もう少し役立ちます。ストアドプロシージャはどうですか?
一部のデータベース(PostgreSQLなど)では、さまざまな言語でストアドプロシージャを作成することもできます。したがって、本当に必要な場合は、SQLの代わりにPythonやJavaなどで記述できます。
OPは、すべてのデータベースコードをアプリケーションコードに直接記述する代わりに、ストアドプロシージャを呼び出すか、HibernateなどのORMを使用してアプリケーションコードとデータベースの間に分離レイヤーを導入することを意味していると思いますが、はい、それらは非常に異なるもの。
ストアド プロシージャを使用すると、SQL をアプリケーション コードとは別の場所に保持できます。Hibernate を使用すると、SQL を完全に記述する必要がなくなり、リレーショナル データベースのオブジェクト表現が提供されます。
どちらに進むかは、アプリケーションと自分の好みに大きく依存します。
うーん、ストアド プロシージャに代わる明白な方法は、アプリケーション コードを記述することだと思います。たとえば、クレジットが転記されるたびに借方を転記するストア プロシージャを記述する代わりに、両方を記述するアプリケーション コードを記述できます。
多分私はここで単純化しすぎているか、質問の要点を逃しています。