3

これは絶対にボンカーですか.....

私は新しいプロジェクトに取り組み始めたばかりで、今見たものにショックを受けています. このプロジェクトは、Oracle データベースの上にある C# Web アプリです。現在、すべてのストアド プロシージャは、実際にはストアド プロシージャではありません..それらは、サーバー上のディレクトリ内のテキスト ファイルに格納されている単なる SQL スクリプトです。アプリケーションが起動すると、ディレクトリを調べて各ファイルを調べ、テキストを読み込んで辞書に保存します。また、[PARAM] などの特殊なシーケンスを削除するテキストに対して Regex を実行し、それらを正しい記号 (Oracle の場合は「:」、SQL SERVER の場合は「@」) に置き換えます。次に、コードがこれらのステートメントのいずれかを実行する必要がある場合、辞書で正しいステートメントを見つけて実行するメソッドを呼び出します。

現在、これは、基盤となる db テクノロジを交換したい場合に備えて行われたようです。彼らは、適切な構文のファイルのディレクトリからSQLファイルを交換するだけでうまくいくと言います。

今、私は通常、ストアド プロシージャが実際にはストアド プロシージャであり、データベース上に存在することを期待しています。データベースと通信する別のプロジェクト (レイヤー)。次に、db テクノロジが変更された場合は、別のデータ層プロジェクトを追加して、dll を交換するだけです....

現在行われている方法には大きな問題があります。

  • 作成中の db サーバーに実行計画がありません。
  • 何百ものテキスト ファイルを読み取り、それぞれの文字列を作成し、その上で正規表現を実行するという、膨大なオーバーヘッド。
  • SQL 構文のチェックなし。
  • これらすべてのストアド プロシージャがメモリ内にある大きなメモリ フット プリント

どう思いますか？

これは本当に悪いことなのか、それとも今まで見たことがないからうめいているだけなのか?

このアプローチには他に何が問題がありますか?

これはクレイジーだと同僚に伝えようとしているので、どんなコメントでも大歓迎です....

4

2 に答える 2

1

ビルド時にスクリプトを使用して、ネイティブ構文（PSQL、T-SQL）でストアドプロシージャスクリプトを作成し、データベースに展開できないのはなぜですか？それがあまりにも多くの作業になるとは思えません。コンパイルされたストアドプロシージャコードなどのすべての利点を得ることができます。

私は、ストアドプロシージャ（SQL Server）の実行時コンパイルが大きなパフォーマンスオーバーヘッドであるという個人的な経験があり、本番システムではこれが実際の問題でした。

私はこのデザインの背後にある理由を見ることができます：

  • ストアドプロシージャコードはデータベース固有であるため、ストアドプロシージャは使用せず、代わりにSQLステートメントを使用します。

  • SQLステートメントにもデータベース固有の構文を含めることができるため、実行時にオンザフライで変換するための簡単な方法があります。

ストアドプロシージャを使用しない場合でも、変換は実行時ではなく、ビルド時に（たとえば、C＃コードを生成するために）実行する必要があると思います。

于 2012-07-20T09:47:49.010 に答える
0

どう思いますか？

これはオーバーエンジニアリングの典型的なケースだと思います。DB プロバイダーを変更するのは誰ですか? それは本当に何かをテーブルにもたらしますか？

これは本当に悪いことなのか、それとも今まで見たことがないからうめいているだけなのか?

私の意見では、両方のビットです。かなり悪いですが、しばらくの間このように実行されていれば、機能しているはずです。

このアプローチで他に何が問題なのですか?

現状では、毎回実行計画を再計算することがおそらく最大の問題です
。パフォーマンスが大幅に低下します。私が言っているのは、おそらくパフォーマンスが常に要件であるとは限らないためです (過剰な最適化はそれ以上良くありません;)
本当に間違っているのは、彼らが車輪を再発明したことです: LINQ はそれをネイティブに行います.
つまり、LINQ が時間の経過とともに改善されるにつれて、同社は機能強化の恩恵を受けないため、着実に後れをとることになります。

何らかの力を持っている場合は、LINQ について話し合ってみてください。

于 2012-07-20T11:31:30.557 に答える