データベース機能が無視され、代わりに中間層で再発明されるのはなぜですか？

今日のほとんどのITプロジェクトがOracle11gやSQLServer 2008などの最新のデータベースエンジンに存在する豊富な機能を無視しているように見える主な理由（「データベースの独立性」を除く）は何ですか？

または、ヘルシンキ宣言のブログから借りるには、次のようにします。

過去20年間で、DBMS内で利用できる機能（機能）が飛躍的に成長していることがわかりました。これらの機能により、データベースアプリケーションを構築することができました。これは、私たち全員が活況を呈している90年代に始めたことです。

しかし、その後、新しい千年紀の夜明けに、何かが起こりました。そして、その何かが、データベースアプリケーションプロジェクト内のDBMSの役割を不思議なことに減少させ、取るに足らないものにしました。（...）新しいミレニアムの時点で、すべてのアプリケーションロジックをDBMSから中間層サーバーにプッシュしています。DBMSの外部に実装されたものの機能は爆発的に増加し、機能豊富なDBMSは行ストレージ以外にはほとんど使用されていません。

私たちは次のようなものについて話している

• データAPIとして使用されるストアドプロシージャ（セキュリティのため、および過剰なネットワークトラフィックを回避するため）
• マテリアライズドビュー
• 代わりに-トリガーの
• 階層クエリ（接続方法）
• 地理（空間データ型）
• 分析（リード、ラグ、ロールアップ、キューブなど）
• 仮想プライベートデータベース（VPD）
• データベースレベルの監査
• フラッシュバッククエリ
• データベースでのXML生成とXSL変換
• データベースからのHTTPコールアウト
• バックグラウンドジョブスケジューラ

これらの機能が使用されていないのはなぜですか？ほとんどのJava、.NET、およびPHP開発者が「SELECT * FROMmytable」アプローチに固執しているのはなぜですか？

ストアドプロシージャのため：

• 別の開発言語を追加し、複雑さと潜在的に冗長なコード（両方の言語で記述されたロジック）を追加します。
• 一般に、PHP、C＃、Java、Pythonなどよりも優れたツール、監視、およびデバッグ機能があります。
• 一般に、ほとんどの中間層言語よりも機能が劣ります。
• 大量のデータ変換（サーバーのラウンドトリップを回避する場合）でのみ利点があります。これは、実際の使用量が最小限になる傾向があります。

そうは言っても、これはC＃ASP.NETアプリケーションで一般的な方法です。

Jeff Atwoodが述べているように、ストアドプロシージャはデータベースのアセンブリ言語であり、必要がない限り、人々はアセンブリ言語でコーディングする傾向がありません。

私はマテリアライズドビューを頻繁に使用し、OracleでCONNECT BYを使用することもありましたが、どちらもMySQLには存在しないと思います。

データベースでXML / XSLTを使用する傾向はありません。これは、XMLとXSLTを使用していることを意味します。

地理的または空間的なデータ構造に関しては、おそらくそれらが単に「拾う」のが難しいという理由があります。それはかなり専門的な分野です。空間データ構造に関するMySQLマニュアルを読みましたが、GISの豊富な経験を持つ人には理にかなっていると思いますが、私と私の限られたニーズ（ポイントの緯度/経度をマークする傾向があります）には意味があります。それを理解するために時間投資する価値はないようです。

もう1つの問題は、ANSI SQLを（はるかに）超えた場合、特定のデータベースベンダー、場合によっては特定のバージョンにある程度結びついていることです。そのため、アプリケーション開発者はデータベースを最小公分母で扱う傾向があることがよくあります。つまり、データベースをリレーショナルデータのダンプグラウンドとして扱うことを意味します。

開発者はSQLについて知らないからです。これらは、Hibernateなどのツールによって生成されたDDLとDML、およびJPAアノテーションなどの言語レベルの構造に依存しています。開発者は、これらが通常のログレベルによって容赦なく隠されており、DBAが開発チームの一部ではないため、これらがひどく非効率的であるかどうかを気にしません。

だから私はツールiBATISが好きです。これらにより、DBMS固有の機能を含むSQLを記述して理解することができます。

理由の1つは、ベンダーロックインの恐れだと思います。

これはそれほど頻繁には言われませんが、ベンダー固有の機能を使用することの利点は、コストと比較検討する必要があります。主に、サポートするすべてのデータベースのベンダー固有の機能に依存する部分を書き直す必要があるコスト。ベンダーがより良い方法を提供しているときに、汎用的な方法で何かを実装すると、パフォーマンスコストも発生します。

この例を紹介します。AnalysisServicesやReportingServicesなどがアプリケーションに対して実行できるすべてのことを理解すると、SQLServerの「ロックイン」がより受け入れやすくなる可能性があります。主要な商用データベースシステムの場合、考慮する必要があるのはSQLデータベースエンジンだけではありません。

「データベース機能が無視されるのはなぜですか」。

多くのいわゆる開発者はデータ管理について完全に無知であり、さらに悪いことに、彼らも彼らの無知について完全に無知です。「熟練しておらず、気づいていない」、これが鐘を鳴らしている。

ソフトウェアがクライアントのハードウェアで実行されている場合、データベースへの変更（新しいストアドプロシージャ、更新されたビューなど）には、DB管理者権限が必要です。これはほとんどの場合、クライアントにとって問題です。DBグループを含めると、必要な更新が複雑になります。ここに示されている大きな理由はたくさんありますが、ペストのようにデータベースにコードを配置することを避ける必要があるのはこれだけです。

理由の1つは、ベンダーロックインの恐れだと思います。これらのDBMS機能は標準化されていません。たとえば、ストアドプロシージャは非常にDB固有であり、ストアドプロシージャを使用して実装した場合（たとえば、中間層を介して公開されるWebサービスの代わりに）、最初に選択したDBMSで永遠に立ち往生します。 、（つまり、DBMSを変更したい場合に、別のDBMSで再実装するために時間/お金を費やすことをいとわない場合を除きます）。

MySQL。

1990年代後半から2000年代初頭にWebアプリケーションが爆発的に増加したとき、MySQLはバージョン3.3または4.0であり、単純なSELECTsを超えるものはサポートしていませんでした。ただし、無料で、ほとんどのLinuxディストリビューションにインストールされていました。その結果、ある世代のプログラマーはデータベースについて学習せず、データベースの使用方法も知りませんでした。

MySQLが5.1であり、商用システムのほとんどの機能をサポートしている今でも、新しいLAMPプロジェクトが開始されると、同じ雑然とした古いブログや記事がテンプレートとして使用され、MySQLはMyISAMテーブルと3.3時代の機能とともに展開されます。 。

SQLは、Haskellなどと同じ理由で失敗しています。言語の成功を決定する指標は、純粋さではなく、コンピューターによる解釈の容易さではなく、言語で書かれたプログラムを維持することがどれほど難しいかです。

最も単純な言語でさえ、単なる死すべき者は失敗します。おそらく、10人に1人は、C＃のような単純な言語を使用するスキルを持っています。しかし、それらの10％のうち、SQLやHaskellなどの言語を効果的に使用できるのは10人に1人または1％にすぎません。

現在、SQLだけでできることはほとんどないという意味で、SQLは言語としては不完全です。常に別の言語が必要になります。それはSQLにどのような役割を残しますか？開発者はフラットファイルストレージに対するACIDの利点を理解しますが、それ以外にデータベースは実際にそれらを提供するものは何もありません。

2番目の問題は、SQLがソースバージョニングと効果的に互換性がないことです。SQLは、最初から正しく理解できるという概念に基づいて構築されているようです。そのため、開発者には適していないだけでなく、開発プロセスにも適していません。

DBMSよりも中間層を修正/再デプロイする方が簡単です。

これはおそらくアーキテクチャによって異なりますが、それが私たちの理由です。それを、忙しくて（おそらく）開発者よりも多く支払われるDBAが1人いるという事実と結び付けてください。すべての開発者はSQLを知っており、一部の開発者は手続き型言語に精通しています。非常に厄介な本番環境の問題が発生した場合、アーキテクチャがどちらの方法で優れているかに関係なく、開発者はデータベースよりも中間層で作業する方が簡単で迅速です。

私は、そのような機能が存在することに気づかなかったかなりの数の人々に出くわしました-彼らはmySQLの初期の頃に歯を食いしばり、実際に他のものを使用したことがなく、彼らは追いついていないmySQLの新しいストレージテーブルの進歩も。または、学校でデータベースを学習しましたが、見逃したものをすべて見に戻ったことはありません。

彼らは、最低限のSQLを習得し、さまざまなRDBMSが提供するさまざまな拡張機能のすべてを理解しているわけではありません。

あるプロジェクトでは、マテリアライズドビューが欲しいのですが...しかし私はPostgresを使用しています。別のプロジェクトで空間データ型を使用したいのですが、ハッキングを行うか、データベースを変更して、それらがnullではないというmySQLの主張に対処する必要があります。mySQLでは問題にならなかったOLTPでの長時間実行クエリを処理するために、Oracleのトランザクション整合性を無効にする方法を理解する必要さえありました。

私は通常、特定の問題に対するデータベースの欠点を回避するためにコーディングできますが、問題の一部は、ジョブに適したツールを選択することです。現在のプロジェクトでは、データレプリケーションに何ヶ月も費やしています。 Postgresを使用して、彼らは私たちが複製するものすべてを実際に知る前にSlony-1を決定しました。

...私はこの質問を「なぜもっと多くの人が言語yで機能xを使用しないのか」のように見ています-彼らが言語yの専門家でなければ、機能xが存在することを知らないかもしれません。

（そして、これをDBA認定取得のサポートとは見なさないでください...ウェットサックから抜け出す方法をプログラムできないOracle DBAをいくつか知っています。私は、8i日間ですべてのコースを受講しましたが、私はそのグループに集中したくなかったので、テストを受けることを拒否しました）

他のすべてを覆い隠す最大の理由は、複数のアプリケーションが同じデータを共有している場合、リレーショナルデータベースシステムが劇的に重要になることだと思います。コッドの有名な論文のタイトルは「大規模共有のデータのリレーショナルモデル」です。データバンクの（私の強調）。

人々は、現在作成しているアプリケーションは常にチームによって制御されると考える傾向があります。また、アプリケーションによって生成されたデータに関心のある人々のすべてのニーズを常に満たすことができます。新しいニーズが発生した場合は、新しいアプリケーションを作成するのではなく、既存のアプリケーションに新しい機能を追加することで対応できます。

しかし、多くの場合（もちろん、すべてではありません。すべての状況が異なります）、その開発モデルは長期的にはうまく機能しません。アプリケーションによって生成されたデータが蓄積され、ビジネスにとってより重要になるにつれて、さまざまな人々がデータの使用方法について興味深いアイデアを持つようになります。その場合、リレーショナルデータベース管理システムがなければ、大きな課題に直面します。

スケーラビリティ。データベースサーバーに与える作業が多いほど、ボトルネックが大きくなります。負荷分散されたアプリケーションサーバーのファーム全体でデータを処理し、データベースを永続ストアとして使用する方がスケーラブルです。

私は企業の政治があまりにも多くの状況にありました（「SQLServerへのアクセスを許可していないので、Accessのようなそれほど強力ではないDBMSをインストールして、数百万の行を処理し、別のテーブルの数百万の行と結合して、そのインポートを自動化しましょう.. "）または発生する可能性のある技術的政治（" Accessがその量のデータを処理できることはわかっていますが、そうでない場合でも、MDBを複数のMDBに分割して参照することができます..... "）

UGH。企業政治や技術政治、あるいは無知でさえ、私が多くの機能を使用することを妨げてきました。

別の例-私は、SQL Serverが100％のMicrosoftショップでストアドプロシージャを使用していない理由に見ない選択肢のDBMSを。しかし、最終的にソリューションを所有する予定だったIT担当者は、SPを「軽視」していたため、他の手段に頼らざるを得ませんでした。つまり、その「機能」の一部が彼らの店で無視された理由の完璧な例があります。

まだDOSFoxpro 2を使用している別のショップを知っています。なぜなら、彼らの唯一のIT担当者が既存のシステムをそのように作成し、それがすべての新しいものを開発する方法だからです。どうして？時代とともに動くことはできませんか？向こうのマーケティング担当者の多くは、一度に複数のDOSプロンプトを開いており、Foxproの「ジョブ」を実行して、これまでに見た中で最も醜いレポートを作成しています。しかし、それは機能します-私は彼らにそれを与えます。それは機能します-メインテーブルに1200万行があり、他の50以上のテーブルがそのメインテーブルと「結合」しています（明らかに一度に50行すべてではありません）が、1991年をはるかに過ぎています！彼らはあなたがあなたの質問で提供したその弾丸リストからの1つの項目について議論することさえ望んでいません。

このようなものが私が推測する理由です。

最大の理由は、ほとんどの人がそれらについて知らないということだと思います。誰かが問題の解決策を見つけたら、それが同様の問題のデフォルトの解決策になります。SELECT * FROMテーブルは長い間多くの人に役立ってきたので、彼らは古い問題への新しいアプローチをわざわざ見ていません。

もう1つの理由は、データベースを使用するよりもコードで記述する方がはるかに簡単な場合があることです。自分でロールするのと、既製のコンポーネントを購入するのと同じ考えです。事前に作成された機能を使用すると、問題を何度も解決できますが、ときどき、事前に作成されたコンポーネントが実行できる機能の範囲外のことを行う必要があります。

いい質問、そして良い議論。

別の言い方をすれば、「オブジェクトDBが捕捉されなかったのはなぜですか？」です。コインの裏側です。DBは引き続き厄介な抽象化であり、そこにあるすべてのアプリにまだ漏れていますが、最新のアプリケーションのOOロジックとは互換性がありません。

ActiveRecord、Hibernate、およびその他のミドルウェアでDBの機能を非表示にして複製するのは、確かに奇妙な状況です。しかし、これは破損の時点でパラダイムに起こることです（「オブジェクト-リレーショナルインピーダンスミスマッチ」）。OOアプリ（オブジェクトDBなど）に類似したデータベーステクノロジーに移行することはありますか？

答えは「長くはない」であり、その間、中間層の機能がギャップを埋めるために成長するにつれて、DBが無視されて押しつぶされ、行ストレージのみに使用されることを期待します。

もう1つの質問は、「中間層で実行できるのに、なぜDBで実行するのか」です。中間層は慣れ親しんでおり、常に速度と機能の面で進歩しています。ここでも、OO-RDMSの不一致を回避するために中間層を使用します。

クリスチャンが何を進めるか言っ、スケーラビリティについて。

単純に、ロジックがアプリケーションサーバーに移行している間、RDBMは純粋なデータストアとしてより多く使用されています。ASの追加の層により、開発者はRDBMSをアプリケーションサーバーとして使用するよりも柔軟性が高くなります。

以前は、FatAppsとClientServerの古典的な時代には、DBとApplicationServerは基本的に同じものでした。ファットクライアントコードにアプリケーションロジックを埋め込むか、RDBMSにプッシュバックしました。しかし、当時の主要な通信形態は、データベースへの直接のSQLでした。

現在、他のアプリケーションプロトコルがより一般的です（CORBA、DCOM、リモートEJB、およびHTTPを介したXML / JSON / HTTP-RPCスタイルのプロトコルがますます一般的になっています）。ほとんどのデータベースはこれらのプロトコルに直接応答しないため、アプリケーション層はこれらの呼び出しをインターセプトするために介入され、その層はデータベースを呼び出します。

しかし、私たちが学んだように、このレイヤーにロジックを組み込むことで、より多くの柔軟性が得られます。ツールの選択肢が広がり、キャッシュやフェイルオーバー、さらにはデータベーステクノロジー（RDMBS、OODBMS、CouchDBなどのドキュメントストア）に対する柔軟性が高まります。その「新しい」第3層は、複雑さが増したにもかかわらず、それがもたらす複雑さよりも柔軟性とパワーを追加します。

アプリ層がストアドプロシージャの上に非常に薄いベニヤである場合、なぜそれがまったく存在しないのかを疑問視するのは有効です。

データベースとそのすべての機能を活用することは、今日でも有効なアプリケーション戦略です。SQL Server、Oracleなどは、非常に強力なソフトウェアです。

それでも、第3層は、最新のシステムに柔軟性を追加するのに非常に役立ちます。

私にとっての理由は、アプリケーションがデータベースに依存しないだけでなく、データベースが基本的なCRUD関数を最もよく実行するためです。ええ、データベースは高度に最適化されており、HTTPコールアウトを作成できる可能性がありますが、なぜそれを行うのでしょうか。Webサービス/ Webアプリケーションは、データベースではなくHTTP呼び出し用に最適化されています。アプリケーションがデータファイルに直接接続してデータを取得するように設計されていないのと同じです。それはできますか？そうだね。でも何で？それはあなたのアプリケーションが優れているものではありません。

個人的には、ストアドプロシージャ以外の、あなたが言及したすべてのものがアプリケーションに属していると感じています。アーキテクチャがXであることがわかっている場合は、Xの機能を利用し、必要に応じてDBサーバーにロードオフするなど... XまたはY（またはZ）の場合は、アプリケーションに依存しないようにする必要があります。アプリケーションをリファクタリングする必要があるかもしれないことを確認することによって、ジョブセキュリティを作成しようとしています:)。少しの怠惰と快適さの組み合わせがそれと関係があるのではないかと思います。可能であれば、SQLよりもC＃で実行したいと思います。。。私のC＃スキルはちょうど良いです。

まず、ORMを使用する開発者は、ORMを使用することで、SQLスキルが必要になることを否定すると考える場合はナイーブです。SQLを生成するほとんどのORMは、オブジェクトクエリの構築方法に応じて発行されるSQLを変化させます。開発者はSQLを分析して、オブジェクトクエリを変更する必要があるかどうかを確認する必要があります。

簡単な答え：これらの機能の多くは、オブジェクト指向開発には実用的ではありません。DBAがそれを聞きたくないことは知っていますが、それは真実です。これらの機能はエッジケースに適しています。N/ Hibernateなどのほとんどの優れたORMでは、これらのエッジケースにSQLを提供できます。

主にCRUDに委任される場合：

長い答え：RDBMSの世界は成熟しつつある苦痛を経験しており、世界でその場所を見つけていると思います。真実：OOPはRDBMSよりも古いです。OOPは、増大する痛みと成熟から抜け出しつつあります。言語としてのSQLは非常に成熟していると思いますが、RDBMSが何を処理すべきかという考えはまだ決着がついています。RDBMSは、JavaとC＃が登場するまで、ほとんどのWebアプリのビジネスロジックホルダーでした。私たちは今、この修正を感じ始めたばかりだと思います。

そうは言っても、RDBMSに供給されるSQLステートメントの品質は重要ではないとORM設計者が言うことはないと思います。

非CRUDに関しては、ここで答えはありません。私が知っているほとんどのショップは、まだETLなどにDBを使用しています...

同じロジックをDBまたは中間層に実装する場合、通常の「中間層」プログラマーに実際に違いをもたらすレベルでこれらすべての機能を知っている開発者は十分ではありません。たぶん、その機能について本当に深い知識を持っているのはDBAだけでしょう。そして、それらは開発以外の問題に焦点を合わせています。DBAよりも多くの「通常の」開発者がいます。したがって、チームに適した人材を見つけることは非常に困難で費用がかかります。

もう1つのポイントは、通常、すべてではなく、1つのデータベースシステムに関する詳細な知識のみを収集するということです。したがって、SQL Serverの専門家またはOracleの専門家を配置できますが、両方を使用することはできません。これは（ある程度）専門性が高いことが重要な狭いアプリケーション分野につながります。そうすれば、そのようなアプリケーションの市場は、たとえそこにあったとしても、それほど大きくはありません。

その理由は、ベンダーロックインとほとんどのRDBMユーザーの知識不足の組み合わせだと思います。SQLはプログラミング言語であり、SQLは特にユニークな言語であるため、SQLを呼び出す言語とSQLの両方を習得することは、どちらか一方を習得するよりもはるかに困難です。

解決策は、データベース機能をユーティリティクラスに抽象化し、SQLで何をしているのかを知っている少数のユーザーにクラスの所有権を与えることだと思います。これにより、ベンダーロックインのリスクが最小限に抑えられます（ベンダーを切り替える場合、書き換えられるのはクラスだけです）。これにより、SQLの専門家ではない開発者にも抽象化されたインターフェイスが提供されるため、データベースを直接処理する必要がありません。

増加したデータベース機能を活用することで私が見た懸念の1つは、スケーリングです。データベースの負荷とWeb /アプリケーションサーバーの負荷をスケーリングすることは、はるかに難しい提案のようです。

オプションは限られており、より高速なハードウェアでスケールアップする（ライセンスコストがはるかに高くなる場合があります）か、複雑で、読み取り専用コピーでスケールアウトするなどです。

パフォーマンスの問題がある場合は、Webサーバーアプリケーションレベルにする必要があります。少なくとも、私のオプションの1つは、別のWebサーバーを追加して負荷を分散することです。

私は、Webサーバーとデータベースサーバーの間で送信されるネットワークトラフィック（レコード）の量を最小限に抑えるために、データベースレベルのコードに反対しているわけではありません。私は他の機能、例えばに反対している。データベースレベルでの広範なビジネスロジック処理。

いくつかの投稿は、データベース層よりもアプリケーション層でスケーリングする方が安価であると述べています。

もう1つの考慮事項は、複数のデータストアにアクセスする複合アプリケーションです。データベース層でプラットフォーム固有のクエリを個別に作成するよりも、アプリ層でプラットフォームに依存しないクエリ言語を記述して維持する方がはるかに簡単です。

ネイティブのホスト言語オブジェクトを使用して、ホスト言語でオブジェクト指向ソフトウェアを作成することは、手続き型ソフトウェアを作成するよりも優れているためです。

私は常に、多くのクライアントに販売され、クライアントのハードウェアで実行されるシステムに取り組んできました。これはにつながります：

• クライアントが実行するデータベースソフトウェアのバージョンがわかりません。
• お客様は、ライセンス費用やITポリシーのために、希望するときにデータベースソフトウェアを更新することをいとわない場合があります。
• マテリアライズドビューのような基本的な機能でさえ、データベースソフトウェアの一部の「エディション」にのみ存在しますが、小規模な顧客は、データベースのハイエンドエディションにお金を払うことをいとわないことがよくあります。
• 遅かれ早かれ、営業担当者の1人が、ソフトウェアが別のベンダーのRDBMSで使用されることに同意するでしょう。
• ロジックを中間層に1回書き込むか、少なくともデータベースにPL-SQLとTSQLを書き込むかを選択するのは簡単です。
• データベースへの変更（新しいストアドプロシージャ、更新されたビューなど）には、DB管理者権限が必要です。これは、一部の顧客サイトでは、ソフトウェアを更新するよりもはるかに難しい場合があります。
• データベースを更新するスクリプトを作成することは、アプリケーションのdllの新しいバージョンをインストールするよりも常に困難です。（最近のほとんどのビルドシステムは、すべてのビルドの一部としてMSIファイルを出力します）
• 中間層よりもデータベースでテストコードを単体テストするのは困難です。
• ストアドプロシージャのデバッグはC＃よりも困難です。
• データベースで機能するからといって、顧客のデータベースで機能するわけではありません。RDBMSには、機能を変更するスイッチが多すぎるため、顧客は常にさまざまな方法でスイッチを設定する傾向があります。

したがって、上記のすべてを考慮すると、データベース機能を使用することによる利益は、長期的な苦痛に見合う前に大きくなければなりません。