DBMSの物語

はじめに

多くの場合、「DBMS」という用語が発音されるとき、それはリレーショナルDBMSのみを意味します（以下、同義語と見なします）-これは主に、現在市場にあるほとんどのDBMSが単なるリレーショナルであるという事実によるものです。 リレーショナルモデルは、2次元テーブルの形式でデータを整理することに焦点を当てており、その実装はEdgar Codd ^1の研究に基づいています。 リレーショナルモデルは良い面と悪い面があります。実装の容易さのために良いのですが、オブジェクト指向プログラミング言語で作業するという観点からは悪いです。

最初の物語。 「データベース内のオブジェクト」

データベースにオブジェクトを保存する問題を解決するために、新しいシステムのクラス全体が作成されました-オブジェクト指向DBMS（および中間オブジェクトリレーショナルDBMS）。 この問題を解決する必要性は、オブジェクト指向プログラミング（OOP）が現在、基本概念がオブジェクトとクラスの概念である主要なプログラミングパラダイムであるという事実によって引き起こされます。 オブジェクト指向プログラミングは、プログラムをオブジェクトのコレクションとして表現するプログラミング方法論であり、各オブジェクトは特定のクラスのインスタンスであり、クラスは継承階層を形成します[Butch]。 OOPは、プログラマーのチームによって開発された大規模なソフトウェアシステムの実装に焦点を当てています。 OOPを使用すると、サブジェクト領域のオブジェクトに対応するプログラムオブジェクトを作成し、オブジェクトを他のプログラムの開発に再利用できるため、新製品の作成プロセスが大幅にスピードアップします。



オブジェクトには、状態、動作、およびアイデンティティがあります。 類似オブジェクトの構造と動作により、それらの共通クラスが決まります。 「クラスインスタンス」と「オブジェクト」という用語は同じ意味で使用されます[Butch]。 DBMSとの対話のコンテキストで最も重要なプロパティは、状態（オブジェクトの属性の合計値）とIDです。 「アイデンティティとは、オブジェクトのプロパティであり、他のすべてのオブジェクトと区別するものです」[Khoshafian]。



KhoshafyanとCopelandは、次のことに注意します。「ほとんどのプログラミングおよびデータベース管理言語では、一時オブジェクトを区別するために名前が付けられているため、アドレス可能性とIDが混乱しています。 ほとんどのデータベースはキー属性によって永続オブジェクトを区別するため、データのアイデンティティと意味が混ざります。



データベース内のオブジェクトの処理に関連する多くの問題は、オブジェクト指向DBMS、たとえばCache ^2で解決されました。 このようなDBMSの使用はまだ普及していません。 したがって、データを格納するための基盤としてオブジェクト指向DBMSを使用するソリューションは、業界標準よりも次の「バイク」である可能性が高いと見なされる必要があります。

2番目の物語。 「ビジネスロジック」

私は絶えず「ベースのすべて」アプローチのために謝罪者に出くわします。 このアプローチの本質は、データベースが意図された目的、つまり、構造化データの配置、選択および変更だけでなく、データベースのフレームワークでのビジネスロジックの積極的な実装のためにも使用されることです。 後者は、単一のDBMSのフレームワーク内でデータとロジックを接続します。これは、魔神をボトルに差し込み、自由になりすべてが壊れる瞬間を待つようなものです。 データベースへのビジネスロジックの統合に関する傾向は、 ^3つのソフトウェアの多数のリファクタリングが必要になった90年代半ばに現れました。



根拠がないようにするために、「ベースのすべて」アプローチを支持する主な議論をします。

1. 安全性 テーブルに権限を付与してからトリガーを使用してデータの安全性を実装するよりも、ストアドプロシージャに権限を付与してデータ処理のロジックを保護する方がはるかに信頼性が高いと考えられています。
2. スピード。 ストアドプロシージャは、DBMSアドレス空間で実行されます。つまり、格納されたデータに近接しているため、システムの応答時間が短縮されます。
3. ストアドプロシージャを開発するための言語専門。 このような言語は、データベース内のデータを操作するために「シャープ」になり、HPの速度にプラスの効果があります。
4. 変更のローカライズ。 システムのロジックの変更は1か所で行われ、ほとんどの場合、クライアントソフトウェアの再コンパイルとその後の再インストールは必要ありません。
5. トラフィックを最小限に抑えます。 トラフィック量の減少は、XP実行の結果が生データではなくユーザーに返されるためです。

これらのステートメントは基本的に正しいので、これらのステートメントについて議論する意味はありません。 ただし、質問を指定した場合、つまり、本格的な「アプリケーションサーバー」を選択して3層アーキテクチャを使用する場合、データベースにビジネスロジックを保存する必要がありますか。 このようなインフラストラクチャを作成することはスタートアップにとって常に正当化されるわけではありませんが、企業で使用するための代替ソリューションは事実上ありません。業界のモンスターは当然、中間層に独自のソリューションを提供します。



上記に基づいて、アプリケーション開発のルールの1つを思い出したいと思います。

「最も重要なことは、ビジネスロジックが同じレベルに集中していることです。 レベルの選択は、特定のタスクに依存します。」

-Sergey Kiselev、技術および開発の共同設立者およびコンサルタント、Ai-Point Rus Research and Production Company LLC。

ビジネスロジックをデータベースレベルにすることは、パフォーマンス、スケーラビリティ、移植性の制御を失い、DBMSメーカーに大きく依存する場所に集中することです。

「アプリケーションロジックをデータベースに転送すると、特定のデータベースに、より正確にはさらに悪いことに特定のバージョンのDBMSにバインドされます。 柔軟性の喪失。 同時に、クロスプラットフォーム実装が何であるかを理解していれば、実装のフレームワーク内のどこにでもロジックを転送することは問題になりません。 これを管理する方法はよく知られています。」

-Victor Gamov、一流プログラマー、教育科学センターMIIT-Expert。

また、私の意見では、主な問題は、デバッグやテストなど、ソフトウェア製品の開発と保守の多くの段階を実行する複雑さに関連しています。 また、「Everything in the Base」アプローチを使用すると、リファクタリングの実装が大幅に複雑になります。

「デバッグが困難なベンダー固有のロジックはリファクタリングの対象ではありません。テストは静的分析によってのみ可能です。 ただし、DBMS側のビジネスロジックについては、おそらく多くの議論があります。 たとえば、パフォーマンスの追求や、データベーステーブルの行のロックの巧妙な管理の必要性などがあります。 これらの場合、これらの欠点はすべて、妥協の不快な結果になります。 そして、開発者は順番に、これらの不利益の犠牲になります。」

-Yandexのプロジェクトマネージャー、Andrey Gura。

もちろん、実装中のビジネスロジックの場所に関する決定は、タスクに基づいて行う必要があります。 同じデータ処理アクションを、DBMSレベルで直接ストアドプロシージャとアプリケーションの両方に実装できるという事実に基づいています。

「すべてのビジネスロジックは、条件付きで「2つの部分」に分割できます。 1つは「データサービス」、2つ目は「適用されたタスクの実装」です。 前者はDBMSに、データの次にはより論理的に、後者はアプリケーションサーバーに保持します。 「データサービス」によって、適用された問題の観点からデータの一貫性のサポートを理解し、プライマリデータから適用され計算されたデータを収集する関数を入力します。

-CJSC BioHimMak、システム管理者、Vladimir Bormotov。

いずれにせよ、特定の決定の採用は開発者にかかっており、開発者は、この問題における各ステップの重要性を理解する必要があります。

3番目の物語。 「ウォーターフォール接続」

開発者のさまざまな記述スタイルと資格にもかかわらず、ほとんどのCMS ⁴システムの内部を見ると、1つの共通の機能に気付くでしょう。これは、開発者がDBMSへの接続を操作する方法です。



数百人が使用する小さなWebプロジェクトと、データベースからコンテンツを取得する一般的なプロセスを想像すると、気のめいるような画像が得られます。 多くの場合、各ユーザーのコンテンツをダウンロードするとき、接続が作成され、データがダウンロードされ、接続が閉じられます-この一見合理化されたプロセスは、ラッシュアワーに不当に多くの消費者が到着すると、DBMSがサービスを拒否されることです。



上記のエラーは、大騒ぎを防ぐ「接続大騒ぎ」[テイト]です。 たとえば、ビジネスプロセスの実行中にいくつかのオブジェクトがデータベースに複数回接続してデータを受信および保存する必要があり、さらに、トランザクションを実行するよりも各接続の作成に時間がかかる場合があります。 DBMSを使用して適切に作業するには、特別なConnectionPoolパターンを使用するだけで十分です。



このパターンの本質は、データベースへの接続数を制御することです（原則として、データベースへの接続数は操作のために制限されます）。これにより、データを取得するプロセスが簡素化されます。 データベースへの接続を取得するには、ConnectionPoolパターンを実装するオブジェクトでgetPooledConnectionメソッドを呼び出す必要があります。その結果、データベースに接続するための接続を取得し、データベースでの作業が終了したら、ConnectionPoolに返すことで接続を解放する必要があります。



ConnectionPoolは、選択された接続数を常に維持しているため、データを受信する時間を自然に最小限に抑えることに注意してください。



説明されたメカニズムにより、システム電力のより効率的な制御が可能になります。 このアプローチを使用すると、単位時間あたりのサービス要求数で表されるシステム全体のパフォーマンスは、メモリ不足[Ch]によって低下しないため、はるかに予測可能になります。

おわりに

多くの企業では、品質ではなくソフトウェア開発の速度が最優先事項です。これは正しくありませんが、回避することはできません。 ほとんどの作業はDBMSでのデータの保存と処理に関連しているため、企業は独自の「自転車」から実績のあるORMフレームワークを利用しています。

文学

[Butch] Butch G. C ++でのアプリケーションの例を使用したオブジェクト指向分析と設計/出版社：Binom、Nevsky Dialect、1998、560 pp。

[Khoshafian] Khoshafian、S。およびCopeland、G。1986年11月。ObjectIdentity。 SIGPLAN Notices vol。21（ll）.p。406。

[Fa] Fowler M.リファクタリング。 既存のコードの改善/ M.ファウラー-サンクトペテルブルク：Symbol-Plus、2004。-432 pp。、Ill。

[Ki] Kerievsky D.テンプレートを使用したリファクタリング/ M。：LLC“ I.D. ウィリアムズ」、2006。-400 p .:病気。

[Tate] Tate B. Javaの苦い味：プログラマーライブラリー/ SP。：Peter、2003.-333 p。

[Ch] Chernousov A.V. エネルギー部門のシステム研究のITインフラストラクチャとその実装のためのテクノロジー/ L.V. Massel、A.V. Chernousov //モデリングと情報技術-KIIV、2006年。



_________

¹ Edgar Coddは、リレーショナルデータベースの理論を確立した英国の科学者です。 1970年、彼は大規模共有データバンクのデータのリレーショナルモデルを公開しました。これは、リレーショナルデータモデルの最初の研究と考えられています。

² InterSystemsCaché公式Webサイトwww.intersystems.com/cache

³リファクタリングまたは再編成は、元の意味と動作を完全かつ正確に維持しながら、コードの可読性とコンポーネントの一般的な内部構造を改善するために、コンピュータープログラムまたはその他の素材を完全または部分的に書き換えるプロセスです（リファクタリング中にエラーが解消された場合-不正な動作を除く） [ファ、キ]。

⁴ CMS-（コンテンツ管理システム）-テキストおよびマルチメディアドキュメント（コンテンツまたはコンテンツ）の作成、編集、管理の共同プロセスをサポートおよび整理するために使用されるコンピュータープログラムまたはシステム。 通常、このコンテンツは、DBMSによって通常管理される構造化データとは対照的に、サブジェクトタスクの非構造化データとして表示されます。 この場合、エントリーレベルのWeb指向のCMSを検討します。