ストアドプロシージャまたはWebのORM？
私は、デスクトップ会計ソフトウェア（。net C＃）を開発しているペルーの会社で働いています。
私たちは多くのクライアント（企業）を抱えており、各顧客は複数の企業を作成できます。さらに、各企業の毎年の新しいデータベースがあります。例：
DBCOMPANY1_2045658512_2015
--------------------------
DBCOMPANY1_2045658512_2016
DBCOMPANY1_2045658512_2017
DBCOMPANY1_2008004100_2016
--------------------------
DBCOMPANY1_2008004100_2017
いくつかの企業へのアクセス、毎月数百または数千の記録、電子請求を利用して商業化できるように、Webに実装したいソフトウェア。
既存のクライアントデータベースはストアプロシージャを使用しますが、既存のすべてのデータベースでトリガーやストアプロシージャを更新するのは不快です。
すべてのデータベースでこれらを更新するのと同じように、ストアドプロシージャを使用することをお勧めしますか？ ORMの場合、システムパフォーマンスにどのように影響しますか？
あなたの場合のストアドプロシージャの問題は、複数のデータベースです。
あなたが指摘するように。 sprocを変更する必要がある場合は、その変更をすべてのデータベースに展開する必要があります。 SQLをコードに保持しているかのように、コードを1回デプロイするだけで済むようになります。
したがって、保守の観点から見ると、コード内のSQLの方が簡単です。
SProcsは、データレイヤーに抽象化のレベルを追加します。これは、別個のデータベースチームがある場合に役立ちます。しかし、最近ではSProcsをスキップすることも珍しくありません。
会社ごとに別々のデータベースには、データが完全に分離されているという追加の保証が追加されるというボーナスがあります。
ただし、1つのデータベースで複数の企業や複数の企業年と連携するようにコードを設計することを検討する必要があります。これは、スケーリングとメンテナンスコストの削減に役立ちます。
ストアドプロシージャとORMの比較は明確ではありません。あなたはその質問の両側で答えを得るでしょう。
ストアドプロシージャは、データベースエンジンがデータテーブルから抽出できる統計およびインデックス情報を使用してプリコンパイルできるという点で、常にORMよりも優れています。そのため、常にパフォーマンスが向上します。しかし、何をしているのかによっては、それほど重要ではない場合があります。たとえば、コールに0.5秒ではなく0.3秒かかる場合などです。
正直なところ、設計の最悪の部分は複数データベースです。可能であれば、単一のデータベースで multitenancy に移動するようにしてください。それはあなたの人生をはるかに容易にします。大きくなりすぎることが心配な場合は、 クラスタリング 、 可用性グループ 、および 分散パーティションビュー を確認できます。
複数のデータベースを維持することを主張する場合は、ストアドプロシージャとトリガーの展開を容易にし、人的エラーを起こしにくい スキーマレプリケーション を調べる必要があります。
興味深い質問であり、ジョン・ウーに同意することは、優先順位とチームの全体的なスキルに依存する明確な「正しい」答えはありません。チームのスキルレベルをC＃とRDBMSで維持することは、私の意見では多くの価値があります。後輩の開発者がデータベースの仕組みを理解していないためにコーディングの恐怖がたくさん見られるので、スキルレベルを上げることでそれを軽減できます。
ストアドプロシージャを選択すると、1つのRDBMSにかなり緊密に結び付けられます。複数をサポートすることは不可能ではありませんが（SAPを参照）、望ましいことではありません。 RDBMSでシステムを実行したい特定の理由がある複数の顧客がいる場合は、ORMを意味するデータベースを抽象化することをお勧めします。
ORMを使用すると、データベースアクセスが簡素化され、直接SQLを使用する必要性の一部が削除されます-ただし100％ではありませんこの点に十分にストレスをかけることはできません。 RDBMSにアクセスするアプリケーションを作成している場合、アプリが非常に簡単でRDBMSの使用が保証されていない場合、または恐ろしいことに我慢して構わない場合を除き、手動でコーディングしたSQLを完全にスキップしてORM経由ですべてを実行する方法はありません。パフォーマンス。 ORMは、データがデータベースに格納される方法とデータベース設計の意味が理解できないという犠牲を払って、データベースを抽象化します。ほとんどの社内システムでは、あるRDBMSから別のRDBMSに簡単にジャンプできるという「メリット」は役に立たないでしょう。大企業がプロジェクトを選択する場合、MySQLに移動するために気まぐれにOracleをドロップすることはありません。莫大な量のSQLといくつかのストアドプロシージャを書き換えるコストは、残りのコストに比べて小さくなります。あなたが販売を得ることがあなたがサポートするあなたの能力（ここに時代遅れのRDBMSを挿入する）とあなたが開発するものに依存することができる小さな会社であるなら、ORMは価値あるオプションであるかもしれません。