Webアプリケーションのデータレイヤーを選択する際に考慮すべき点は何ですか？
リレーショナルデータベースよりもドキュメントデータベースを使用し、大規模で高負荷のプロジェクトを開発する場合、またはその逆の場合に、望ましい選択肢はありますか？
これらのアプローチには、どのような種類のデータベースアーキテクチャが推奨されますか。関係が多すぎない単純なデータベースがある場合は、あるアプローチを別のアプローチよりも使用する方がよいでしょうか。
6767 次
1 に答える
56
この質問は個人的なコメントを募集しているので、ここに私の意見があります：
SQL Serverは、アドホックレポートデータ以外のものを格納するためのデータベースではありません。そのため、アドホックレポート、データマイニング、リアルタイムの関係の発見は素晴らしいです。Coddがルールを設計したとき、それが設計されたものであるため、これらの用途に最適です（詳細については、データ駆動型陰謀を参照してください）。詳細）
もちろん、他の種類のデータをリレーショナルデータベースに保存することもできます。たとえば、ドメインの状態をSQL Serverデータベースにシリアル化し、後日その状態を取得できますが、これはリレーショナルシステムのひどい使用法です。実際、非常に悪いので、この種のタスクをリモートで実行可能、テスト可能、保守可能にするためには、コードのレイヤー全体（いわゆる「データレイヤー」またはDAL）、数千行が必要です。
SQLベースの小売業者は、根本的に異なるデータ構造間のリアルタイム変換以外に階層/ドキュメントデータを格納するためのより良い方法はないと私たちに確信させてきました。DALと最新のORMはすべて打ちのめされていますが、結局のところ、これらは、ディスク上のさまざまなパターンなど、さまざまなデータ組織間でビットを行き来させるコーデックにすぎません。
狂気！
ですから、原子性、一貫性、分離性、耐久性についての愚かな、ピンヘッドの天使の議論をすべて忘れてください。部屋の中の象は、SQL Serverを使用していて、大規模な集団内の隠された推論のためにデータキューブを動的にマイニングしている製薬会社ではない場合（あなたですか？）、データを保存するために間違ったテクノロジーを使用している可能性があります。
一方、あなたが謙虚なアプリケーション開発者である場合-私たちのほとんどのように、まったく新しいイデオロギーと構文のセットを学ぶことを意味しない方法でドメイン状態をシリアル化することを単に望んでいるコーダーのために、リレーショナルデータベースを使用しないでください。しないでください。
RavenDB？私はこれをしばらく使用していて（DB4OとCouchBaseを介して進化してきました）、缶に書かれていることを実行していると言えます。それは私のものを保存し、私が尋ねるとそれを私に返します。データレイヤーを作成したり、サードパーティのORMを使用したりする必要はありませんでした。構造化されたクエリ言語を学ぶ必要はなく、全文検索を機能させるために追加機能を追加する必要もありませんでした（RavenDBはLuceneに基づいているため、すべて「正常に機能」します）。ここまでは順調ですね。
しかし、実際には、目前のタスクにとって、コーディングが簡単で、高速で効率的である限り、何を使用するかは重要ですか？通常のアプリケーション開発では、RavenDBがこれらすべてですが、SQLServerはそうではありません。リレーショナルDBが悪いと言っているわけではありません-被害者のせいにしないでください-特定の特殊な開発では、リレーショナルデータストアなどのエキゾチックなものが実際に必要になる可能性があることを十分に認識しています。
しかし、まだ残骸にしがみついている場合に備えて、これを自問する必要があります。アプリケーション開発者としてのニーズにぴったり合ったシンプルで高速でエレガントなデータストアを使用していた場合は、次のように促す意見記事を書きました。 SQL Serverを採用すると、おそらく私を笑ったり、同情したりするでしょう。1つ確かなことは、SQLServerにスワップしないことです。したがって、慣性だけがSQLServerを主流に引き留める指針となる力であることを示します。慣性と無知。慣性、無知、そして企業の欲望…。
于 2012-05-09T15:13:53.903 に答える