6

私たちは、新しい内部アプリの新しいフレームワークとビジネスの方法を設定中です。現在の設計では、すべてのセキュリティ ロジックをデータベースで処理する必要があり、すべての情報 (つまりすべて) はストアド プロシージャを介してデータベースに出入りします。

理論的には、データ アクセス レイヤーはストアド プロシージャから情報を要求し、認証をデータベースに渡します。データベースは、ユーザーの役割/権限を決定し、タスクを実行するかどうか (データの取得か更新か) を決定します。

これは、データベース トランザクションが少なくなることを意味すると思います。データベースへの 1 回の呼び出し。セキュリティがデータ アクセス レイヤーにある場合、ユーザーが適切なアクセス許可を持っているかどうかを判断するために 1 回のデータベース呼び出しが必要であり、その後、アクションを実行するために 1 回の別のデータベース呼び出しが必要になります。

私は、SQL Management Studio が IDE として完全に欠けていることに気づきました。私の主な懸念は、パフォーマンスの向上を最小限に抑えるために、ストアド プロシージャに大量のビジネス ロジックを維持しなければならなくなることです。

現在、ORM に LINQ を使用しています。軽くて速いように見えますが、何よりも、急速に開発するのが本当に簡単です.

メンテナンス コストは、パフォーマンスの向上に見合っていますか? 顕著なパフォーマンスの向上さえあると思い込んでいるでしょうか? それとも、私たちは自分自身のために悪夢を作っているだけですか?

私たちの環境:

  • 社内のミッション クリティカルではないビジネス アプリ
  • C#/ASP.NET 3.5
  • Windows 2003
  • Microsoft SQL Server 2005
  • 約 500 人のユーザーを持つ 35 の中規模 Web アプリ
4

8 に答える 8

8

そうしないでください。「データベースの第一人者」が別の会社に行くことを決めたとき、私たちは最近非常に悪い経験をしました。手順のすべてのロジックのメンテナンスは、まさに恐ろしいものです!!

はい、ある程度のパフォーマンスは向上しますが、それだけの価値はありません。実際、内部アプリケーションではパフォーマンスは大きな問題ではありません。優れたサーバーにより多くの投資を行います。それは報われるでしょう。

于 2008-09-11T05:30:19.957 に答える
3

残念ながら、「唯一の正解」はありません。選択する必要があるのは、次のような複数の要因によって異なります。

  • チームが与えられたソリューションに精通していること (つまり、チームの大半が SQL の記述に慣れている場合はデータベースにある可能性がありますが、大多数が C# に慣れている場合はコードにあるはずです)
  • 各党の「政治力」
  • 等

どの方向にも決定的な利点はありません (パフォーマンスの向上は最小限であると言ったように)。覚えておくべきことの 1 つは、DRY (Don't Repeat Yourself) の原則です。機能を 2 回再実装しないでください (コード内と同期を維持するのは悪夢になるからです。解決策を 1 つ選び、それに固執します。

于 2008-09-11T05:35:27.153 に答える
2

私見では：

アプリケーション サービス層 -> アプリケーション ロジックと検証
アプリケーション データ層 -> データ ロジックとセキュリティ
データベース -> データ整合性

あなたは遅かれ早かれ sproc アプローチに噛まれるでしょう、私はこれを苦労して学びました。
Procs は、多くのパフォーマンスを必要とする 1 回限りの操作に適していますが、CRUD の部分はデータ層の仕事です。

于 2008-09-11T19:25:34.503 に答える
2

あなたはそれを行うことができますが、開発して維持するのは非常に苦痛です。ほぼすべてのビジネス ロジックがストアド プロシージャでコーディングされているプロジェクトに参加している人から聞いてください。

セキュリティのために、ASP.NET にはユーザーとロールの管理が組み込まれているため、データベースへのアクセスを節約できるかもしれません。引き換えに、システム エラーや検証エラーを処理してデバッグするのは、データベースからバブルアップする必要があるため、はるかに煩わしくなります。

単体テストの sproc に使用できるフレームワークはあまり開発されていないため、単体テストははるかに困難です。

適切な oop とドメイン駆動型の設計は、ほとんど実現されていません。

そして、パフォーマンスの向上は、あったとしてもごくわずかです。これについてはここで話しました。

開発者として正気を保ちたい場合は、データベースを永続化レイヤーのみとして保持するために全力を尽くすことをお勧めします

于 2008-09-11T05:31:34.430 に答える
1

通常、ストアド プロシージャはセキュリティに有利です。アプリケーションとデータベースの関係を単純化すると、エラーが発生する可能性のある場所の数が減ります。ビジネス ロジックをデータベースに接続するコードのエラーは、セキュリティの問題である傾向があります。したがって、データベース管理者はストアド プロシージャにロックダウンすることについて間違っていません。

アプリケーションをストアド プロシージャにロックダウンするもう 1 つの利点は、アプリ スタックのデータベース接続の特権を特定のストアド プロシージャ呼び出しだけにロックダウンできることです。

アプリケーションのセキュリティ ロジックに DBA を関与させる利点は、さまざまなアプリの機能とロールをデータベース内でビューに分割できることです。これにより、動的 SQL と一般的な選択ステートメントが必要な場合でも、SQL の脆弱性による損害を回避できます。制約することができます。

もちろん、これの裏側は柔軟性が失われていることです。ORM は、明らかに、ストアド プロシージャのパラメータについて DBA と絶えず交渉するよりも開発が速くなります。そして、これらのストアド プロシージャへのプレッシャーが高まるにつれて、プロシージャ自体が動的 SQL に頼る可能性がますます高くなりますが、動的 SQL は、アプリケーションで構成された SQL と同じように攻撃に対して脆弱になります。

ここには幸せな妥協点があり、それを見つけようとする必要があります。私が最近取り組んだプロジェクトでは、DBA がデータベース、その接続、およびストアド プロシージャを「最小限の権限」で慎重に構成し、データベース ユーザーが自分の権限を持つものだけにアクセスできるようにしたため、かなりひどい SQL インジェクションの問題から救われました。知っておく必要があります。

明らかに、アプリ ロジックで SQL コードを記述するときは、パラメータ化された準備済みステートメントを一貫して使用していること、入力をサニタイズしていること、国際化された入力に注意していることを確認してください (単一の-quote over HTTP)、入力が列幅に対して大きすぎる場合のデータベースの動作に注意してください。

于 2008-09-11T19:22:24.700 に答える
1

それはすべてあなたのケースに依存します.SPルートに行かず、すべてをDDDの方法で行う方が良いでしょう(コードでドメインモデルを作成し、それを使用します).

しかし、自分のアプリケーションだけでなく多くの人が使用するデータベースがある場合は、おそらく Web サービスを検討する必要があります。いずれにせよ、データベースは、ビジネス ルールを適用する 1 つのレイヤーを介してのみアクセスできるようにする必要があります。そうしないと、「汚れた」データになってしまい、後でデータをサニタイズすることは、いくつかのビジネス ルールを事前に記述するよりもはるかに大きな苦痛になります。優れたデータベースにはチェック制約とインデックスが設定されている必要があるため、好むと好まざるとにかかわらず、いくつかのビジネス ルールがあります。

また、何百万、何十億ものレコードを処理する必要がある場合は、問題を解決してくれる優れた DB-guy があれば幸いです。

于 2008-09-11T07:34:33.077 に答える
0

私の意見では、アプリケーション自体が認証と承認を処理する必要があります。データベース側では、必要に応じてデータの暗号化のみを処理する必要があります。

于 2008-09-11T05:37:48.987 に答える
0

過去にストアド プロシージャ ベースのアプリケーションを作成したことがあります。あなたの場合、データベース層で認証を維持し、ビジネス ロジックを C# にする方法があるかもしれません。ビューを使用してデータを制限します (権限のある行のみが表示されます)。これらのビューは、テーブルと同じように簡単に LINQ で使用できます。ストアド プロシージャを使用して更新を行うように設定します。

これにより、linq、C# のビジネス ロジック、およびデータへのアクセスを制御するデータベースの共通認証レイヤーが可能になります。

于 2008-09-11T05:55:52.937 に答える