2

私は、(主に) SQL Server (2000)、ColdFusion (8)、および一部の Access/.NET アプリケーションに基づく金融サービス業界のプロジェクトに取り組み始めました。このプロジェクトは、いくつかの単純な Access フォーム/VBA として開始され、ゆっくりと Web インターフェイスに変換されました。

データベースの設計とアプリケーションのコーディングは、仕事で学んでいて、最初から優れた設計原則について学ぶ機会がなかった人々によって行われたと言えます。ビジネス ルールの多くは、無数のカスケード関数とストアド プロシージャ、および Web サーバー テンプレートで設定されます。コメント化されていない定数を使用する複雑な 500 行の SQL UDF の奥深くには、膨大な量の特殊なケース処理があります。クエリに関係する可能性のある 10 ～ 20 個の UDF 間の相互作用をすべて追跡することは非常に困難です。一部のクエリは、実行に時間がかかりすぎるようです (最大 15 分)。

テーブルは十分にインデックス化されていますが、FK リレーションシップがなく、参照整合性がほとんどありません。DB は、少量の毎日のバッチ (複数のテーブルに 1,000 レコード) で頻繁に更新されません。主に、データ リポジトリとして機能するために使用されます (データ ウェアハウスだと思います)。デッドロックや遅延が発生することはほとんどありません。

それで、私の質問は次のとおりです。データベースとフロントエンドを含むプロジェクト全体を再実装したい場合、非リレーショナル実装を検討するのは理にかなっていますか? プライマリ DB は約 1GB (.mdf) しかないため、メモリに簡単に収まります。SQL クエリ構造から、効率的にコンパイルおよび実行できる宣言型モデルに移行したいと考えています。必要に応じて、SQL DB を単なるデータ ストアとして使用できます。

4

2 に答える 2

1
  • データベースとフロントエンドを含むプロジェクト全体を再実装したい場合、非リレーショナル実装を検討することは理にかなっていますか?

一般に、ほとんどの開発者は、map/reduce を使用し、NoSQL T シャツを着ている人でさえ、SQL をより快適に使用できると感じています。

アプリケーションが従来の MVC/MVP モデルに従っている場合、ほとんどのフレームワーク (Spring、Rails、Grails、Django、Webmachine など) には、実際には SQL バックエンドのファースト クラスサポートが付属しています。また、NoSQL のサポートもいくつかあります。

NoSQL がシステムにもたらす実際の利点が見られない場合 (別の質問に投稿した利点を次に示します)、なぜ気にする必要がありますか?

  • 基礎となる生データからアプリケーション (Web) で直接使用できるフォームへの変換を記述する一連の「英語」ルールが必要です。

その上にサービス層がある古典的な永続化層について話しているようです。サービスレイヤーのメソッドはどこ"english-language" rulesにありますか。より洗練されたルール エンジンが必要でない限り、ほとんどの場合は必要ありません。"english-language"

于 2011-09-26T01:07:03.963 に答える
1

なぜリレーショナル アプローチから移行したいのですか? リレーショナル アプローチから移行すると、他のアプローチを使用してビジネス ロジックをコードの奥深くに埋め込むことになります。ご指摘のとおり、データ モデルはかなり単純です。まず、データ モデル自体の改善に目を向けることができます。それらが参照整合性制約ではない可能性がある理由は、最初の設計者がこれがパフォーマンスの低下につながると想定した可能性があるためです。彼らは、それ自体が非効率なコードを使用してチェックを行っている可能性があります。

あなたのDBは小さいです。参照整合性制約を追加しても、パフォーマンスにはまったく影響しません。必要に応じて、UDF の一部を書き換えることができます。クエリ アナライザーを使用してパフォーマンス メトリックを確認してみませんか? これにより、分析の良い出発点が得られます。

于 2010-01-29T06:52:51.630 に答える