3

最近、ビジネスオブジェクト/エンティティをデータベースに保存するのに何がうまくいくのか疑問に思っています。議論の目的で、いくつかのアイテム（顧客の詳細、名前、数量、価格など）を含む注文の例を考えてみましょう。SQL ServerとC＃を使用しており、古いプロジェクト用にいくつかのレガシーASP Classic / Jscriptがあり、NoSQLタイプのソリューションなどに移行する機会はありません。

私が知っているおおよそ3つの方法があります

  1. サーバー側でアドホックSQLクエリを作成します（サーバー側の言語を変更した場合は、このコードをすべて再作成する必要があります）

  2. 注文のXML表現を受け入れるストアドプロシージャを使用すると、ストアドプロシージャがドキュメントを読み取り、必要な処理を実行します。（これは私たちが今まで使ってきた方法です）

  3. ある種のORMテクノロジーを使用します（一部の人はそれを誓いますが、それが私たちが行きたい道であるかどうかを正確に判断するのに十分な経験がなく、周りに十分なおしゃべりがあるので、それを避けたいと思いますKISSの哲学を採用して、他のすべてが進行中であることを考えると、パフォーマンスの問題と複雑さをコミットするのに少し神経質になっています）

私が知りたいのは：

  1. 上記のリストにない、調査できる他の/より良いアプローチがあるかどうか

  2. XMLメソッドが標準/グッドプラクティスであるかどうか。ほとんどの言語がXMLへのシリアル化をサポートしているため、Webに対応し、デバッグ中に読みやすく、非常に柔軟です（拡張が簡単で、スキーマなどを介して強さまたは弱さを選択できます）が、他のアイデアを検討する機会があります。

注：SQL Server 2008のストアドプロシージャでOPENXMLを使用する-INSERTの順序はXMLドキュメントとは異なり、いくつかの点で関連しているようです。これまでopenxml（）を使用してきたので、XMLメソッドが妥当な方法であるかどうかを尋ねる質問があると思いますが、XQueryの方が優れたアプローチですか？柔軟性、読みやすさなどの観点から、この方法で物事を行うための本当に最良の方法について誰かが指摘できる便利なリファレンス/投稿はありますか？

編集：返信してくれてありがとう。これが閉じられたとしても、私は応答します（StackOverflowで議論が冗長になっている理由はまだはっきりしていません）。しばらくお待ちいただきましたことをお詫び申し上げます。

私はおそらく明確にする必要があります。XMLが役立つことがわかったのは、いくつかの小さなビジネスオブジェクトで構成される「複雑な」オブジェクトがある場合です。たとえば、「アイテム」を含む注文。アイテムの数が1つ以上ある場合があります。注文を読み込んでから、ユーザーが注文にアイテムを追加した場合、別のアイテムを追加し、XMLにシリアル化してから、それが挿入か更新かを判断できるストアドプロシージャに渡しますが、私はそうではありません。それ以外の方法でそれを行う方法を確認してください（私が避けたい多くの小さなストアドプロシージャ/アドホックSQLは別として。ORM：以下のコメントを参照してください）。行の挿入/更新に相当するフラットな構造を扱っている場合は、厳密に型指定されたパラメーターを使用した通常のストアドプロシージャが適切に機能します。

ORMに関するその他のコメントについては、マーティン・ファウラーの作品へのリンクは興味深いものでした。私はしばらく前に元のhttp://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspxを読みましたが、常により多くの情報に感謝しています。現時点でのORMに関する私の主な関心事は、ORMの使用方法を学ぶことの複雑さであり、現在使用している環境を考えると、ORMをうまく使用すること（落とし穴などを回避することなど）は、処理するのが少し難しいように見えます。

しかし、返信に感謝します。私たちが見逃したかもしれない他のアプローチがあるかどうかを見たかっただけです。ORMは、しばらく投資する価値のあるもののようです。

再度、感謝します。

-マーシン

4

3 に答える 3

1

複数のプログラミング環境から再利用できるように、ビジネスロジックとアプリのかなりの部分（つまり、ストアドプロシージャ）をデータベースに保持したい場合がありますか？その場合は、XMLをストアドプロシージャに送信することで参加できると思います。

私の通常のバイアスは完全に反対で、.NET2.0以降を使用するプロジェクトでNHibernateを使用することを好みます。ORMを使用するための学習曲線がありますが、開発者の生産性が大幅に向上し、強い型付けが非常に多くなります。さらに、最近の.NETリリースではLinqも利用できます。

シナリオでは、NoSQL（RavenDBなど）を検討する価値があると思います。

パフォーマンスに関しては、動的SQLとORMによってストアドプロシージャのパフォーマンスに非常に近づく可能性が非常に高く、通常、必要に応じて金属に近づく方法があります。一般的に遅いXMLの解析のパフォーマンスにもっと関心があります。XMLの解析も脆弱です。

あなたの状況では、データベースと通信しているアプリを最新バージョンの.NETに移動し、ビジネスロジックをデータベースレイヤーから移動することを提唱している可能性があります。長期的には、処理している断片化された環境を継続するよりも、総保守コストが低くなる可能性があります。しかし、これを管理者に納得させることがいかに難しいかは理解しています。

于 2012-09-06T14:34:30.133 に答える
1

2つのプロジェクトで以下を非常にうまく使用しました。

各ビジネス・オブジェクトは、それを作成/更新/削除するデータベース内の1つ以上のストアード・プロシージャーを取得します。（「CRUD」と呼ばれることもあります）この手順では、フロントエンド/Webサーバーをデータベース構造から完全に分離します。

はい、すべてのオブジェクトに対してこれらを作成する必要があり（SSMS-Tools for Management Studioなど、それらの基本バージョンを生成するためのツールがあります）、はい、すべての新しいフィールドに対してこれらを拡張する必要があります。ただし、XMLを使用してデータを転送する場合は、現在のXML解析手順も変更する必要があります。XMLを使用すると、プロシージャの署名を変更する必要がなくなりますが、DIDを転送するデータの構造が変更されるため、これは不正行為に少し似ています。XML内に隠しているだけです。

フロントエンド/Webサーバー側では、すべてのビジネスオブジェクトにそれらを保存するメソッドを提供する必要があります。このメソッドは、関連するプロシージャを呼び出して、すべてのフィールドをそれに渡します。名前付きパラメーターを使用する場合は、パラメーターの順序にも依存せず、オプションのパラメーターを省略できます。これにより、呼び出しごとに変更することなく、プロシージャーを拡張できます。

CRUDメソッドは、XMLの作成や解析を行う必要がなく、プロシージャが目前のケースを正確に処理できるため、非常に高速です。そのようなデータベース。また、手順が小さい傾向があるため、バグを簡単に見つけることができます。

あなたの場合、XMLのシリアル化と逆シリアル化には意味がありません。とにかくネイティブのDB-Client/Driverが必要であり、それは異なるタイプの複数のフィールドの受け渡しを非常にうまく処理できます。WebサーバーコードはDBへのクリーンな呼び出しで終わり、DBはXMLの解析を処理する必要がありません。これは主要な仕事ではありません。

于 2012-09-06T15:15:29.410 に答える
1

オブジェクトに関してSQLServerに何を保存しているのかをさらに明確にする必要がありますが、ビジネスオブジェクトの表現としてXMLをデータベースに保存するだけの場合は、そうではないことをお勧めします。リレーショナルデータベースを最大限に活用します。

適切に設計されたデータベースは、制約を介したビジネスルールの適用、外部キーを介した参照整合性の強化に役立ち、XMLを特定のテーブルに格納するだけの場合には見逃してしまう可能性のある他の多くの利点を提供します。

ストアドプロシージャへのパラメータとしてXMLを使用することに関して、Erland Sommarskogは、XMLを含むこれを処理する方法のオプションに関するいくつかの優れた資料を持っています。彼はまた、OPENXMLについて次のように述べています。

すでにSQL2000では、OPENXML関数のおかげでXMLを使用できます。OPENXMLはSQL2005とSQL2008にまだ存在しますが、それを使用する唯一の理由は、SQL2000もサポートする必要があるということです。OPENXMLは使用するのがかさばり、パフォーマンスはノードにほど遠いです。実際、私のテストでは、反復法よりも30〜50％遅くなっています。ただし、OPENXMLで考えられる利点の1つは、クエリプランが単純なことです。XQueryのクエリプランはXML演算子と関係演算子を組み合わせていますが、OPENXMLは1回のリモートスキャンになります。これにより、XQueryで発生することがあるクエリプランの障害のリスクが軽減されます。

Martin Fowlerは、OrmHateに関するすばらしい記事も持っています。これは、ORMフレームワークの使用に人々が気が進まない理由のいくつかについて本当に素晴らしい議論を提供します。彼は提案することによって彼の記事を終えます。

したがって、ORMは、ほとんどのエンタープライズアプリケーションの非常に現実的な問題に対処するのに役立ちます。確かにそれらは誤用されることが多く、根本的な問題を回避できる場合もあります。それらはきれいなツールではありませんが、それらが取り組む問題も正確にはかわいいものではありません。彼らはもう少し尊敬と理解に値すると思います。

あなたの場合、習得するにはかなりの時間がかかるので、これは非常に適切だと思います。

したがって、オプション2（XML）に傾倒して、最初にXMLを構築する方法に目的の順序を組み込むか、ノードとノードの組み合わせで何が可能かを検討する傾向があります。 SQLServerのROW_NUMBER関数。

于 2012-09-06T15:42:09.070 に答える