5

データベースに保存されているデータを使用して、新しいWebアプリケーションを構築しています。多くのWebアプリケーションと同じように、複雑なSQLクエリ（複数のテーブルからの条件を使用したクエリ）からのデータを公開する必要があります。アプリケーションでクエリを作成するのではなく、SQLビューとしてデータベースにクエリを作成するのが良いかどうか疑問に思っていました。私はそれの利点は何でしょうか？データベースのパフォーマンス？コーディングは長くなりますか？もっと長くデバッグしますか？

ありがとうございました

4

7 に答える 7

7

ケースバイケースであるため、これは客観的に答えることはできません。

ビュー、関数、トリガー、およびストアドプロシージャを使用すると、アプリケーションのロジックの一部をデータベースレイヤーに移動できます。

これにはいくつかの利点があります。

  • パフォーマンス-データのラウンドトリップを回避でき、特定の処理は、DBMS機能の全範囲を使用してより効率的に処理されます。
  • 一貫性-データの一部の処理は、DBMS機能を使用するとより簡単に表現できます。

しかし、特定の欠点もあります：

  • 移植性-DBMSの特定の機能に依存するほど、アプリケーションの移植性は低下します。
  • 保守性-ロジックは2つの異なるテクノロジーに分散しているため、保守にはより多くのスキルが必要であり、ローカルな推論はより困難です。

SQL92標準に固執する場合、それは良いトレードオフです。

私の2セント。

于 2012-06-13T14:56:45.330 に答える
1

あなたの質問は、あなたが達成しようとしていること（SQLビューまたはアプリケーションの構造化方法に関する知識を得る）について少し混乱していると思います。

すべてのデータベースロジックはデータベース層に格納する必要があり、理想的にはストアドプロシージャに格納し、アプリケーションロジックではなく機能させる必要があると思います。次に、アプリケーションロジックはデータベースに接続し、これらのプロシージャ/関数からデータを取得してから、このデータをアプリケーションに公開する必要があります。

これをデータベース層に格納する利点の1つは、SQL Serverを介して実行プランを利用できることです（アプリケーションロジックを介して直接アクセスすることでは得られない場合があります）。もう1つの利点は、アプリケーションを分離できることです。つまり、データベースを変更する必要がある場合は、アプリケーションを直接変更する必要がありません。

ビューの直接的なポイントとして、ビューを使用する利点は次のとおりです。

  • ユーザーをテーブル内の特定の行に制限します。たとえば、従業員が自分の作業を記録している行のみを労働追跡テーブルに表示できるようにします。

  • ユーザーを特定の列に制限します。たとえば、給与計算で働いていない従業員が従業員テーブルの名前、オフィス、勤務先電話番号、および部門の列を表示できるようにしますが、給与情報や個人情報の列は表示しないようにします。

  • 複数のテーブルの列を結合して、単一のテーブルのように見せます。

http://msdn.microsoft.com/en-us/library/aa214068(v=sql.80).aspx

于 2012-06-13T14:56:46.140 に答える
0

ビューは2つのことを行うためによく使用されることを確認しました。

  1. クエリを単純化します。複数の結合と結合および結合を含む巨大な選択がある場合、同じパフォーマンスを持つビューを作成できますが、クエリは数行になります。
  2. セキュリティ上の理由から、すべての開発者がアクセスしてはならない情報を含むテーブルがある場合は、ビューを作成し、メインテーブルであるIEではなくビューを表示する権限を付与できます table 1: Name, Last_name, User_ID, credit_card, social_security。ビューテーブルを作成します。table view: name, last_name, user_id。
于 2012-06-13T14:56:20.263 に答える
0

個人的には、ビューを好みます。特に、データに問題があるかのように、アプリを再構築したりクエリを手動で編集したりするのではなく、単一のビューを更新するだけでよいように、ビューを好みます。

于 2012-06-13T14:50:33.870 に答える
0

ビューに対して実行できるタイプクエリで、パフォーマンスの問題や制約が発生する可能性があります。

ビューでできることの制限。

私の経験では、適切なエンジンを使用し、適切に調整された（たとえば、適切なkey_buffer値の設定）適切にインデックス付けされたテーブルは、ビューよりも優れたパフォーマンスを発揮します。

または、他のテーブルの結果に基づいてテーブルを更新するトリガーを作成することもできます。http://dev.mysql.com/doc/refman/5.6/en/triggers.html

于 2012-06-13T14:51:40.603 に答える
0

SQLビューには多くの用途があります。最初にそれらについて読んでから、より具体的な質問をしてみてください。

于 2012-06-13T14:51:48.847 に答える
0

あなたが言っている技術は非正規化と呼ばれています。FlickrのソフトウェアエンジニアであるCalHendersonは、この技術を公然とサポートしています。

理論的JOINには、操作は最もコストのかかる操作の1つであるため、ビューから選択するmおよびn個のクエリを使用してn個のクエリをm in 1クエリに変換するため、非正規化することをお勧めします。 JOIN JOIN

とはいえ、最善の方法は自分でテストすることです。Flickrにとって信じられないほど良いことは、アプリケーションにとってそれほど良くないかもしれないからです。

さらに、ビューのパフォーマンスはRBDMSごとに大きく異なる場合があります。たとえば、RBDMSに応じて、元のテーブルが変更されたときにビューを更新したり、インデックスを設定したりできます。

于 2012-06-13T15:08:28.793 に答える