C++アプリケーション用のSQLコードを格納する場所は？

Question

私たちは、いくつかの基本的なAPIを使用して生のクエリをMS SQL Serverに送るC++アプリケーションを持っています。私たちのプログラムのさまざまな翻訳単位には、C++の文字列として1-2行の簡単なクエリがあり、今は20行以上にわたるより複雑なクエリが表示されます。

大規模なクエリ、特に20行以上のクエリは、定数文字列としてC++コードに埋め込むべきではないと思います。私はこれらをC++アプリケーションでオンデマンドでロードされる別々のテキストファイルにプルすることを提案したいと思いますが、これが最善のアプローチかどうかはわかりません。

このような状況の典型的な選択肢は何ですか？私は間違いなく改善が必要だと感じている、私はちょうどSQLのクエリをデータファイル（テキストファイル）に移動することが最善の考えであるかどうか分からない。

Answer 1

あなたはDAL（データアクセス層）を作ることができます。

プログラムの残りの部分が話すのはAPIです。その後、メインプログラムを妨害することなく、何かとすべてを（ストアドプロシージャ、キャッシングなど）使いこなすことができます。

Answer 2

自分のファイルに移動することも、独自のストアドプロシージャに移動することもできます。アプリケーションに組み込まれたクエリは、再コンパイルなしで変更することはできません。また、リリース手順によっては、緊急事態への対応やホットフィックスの展開が著しく損なわれる可能性があります。あなたは、道路を降りるとファイルの内容をキャッシュするようにアプリを変更したり、ファイルの更新を定期的にチェックしたりすることもできます。

Answer 3

多くの異なる理由から、最良の「設計選択」は、可能な限り、いつでもMSSQLストアドプロシージャを使用することです。

SQLクエリを共通のモジュールに分離するコードを見たことがありますが、SQLクエリが文字列としてスペルされているため、一般的な "クエリモジュール"（またはスタンドアロンのテキストファイル）それらを呼び出すモジュール内のリテラル。

ストアドプロシージャは、一方で、モジュール性を高め、セキュリティを強化し、パフォーマンスを大幅に向上させることができます。

私見...

Answer 4

私は、SQLをそれを使用するC++関数に埋め込んでおきます。コードの内容を読みやすく理解することができます。

コードの周囲にSQLクエリが散在している場合は、使用しているクラスの全体的な構造に問題があると言えます。いくつか（またはただ1つ）の '低レベル'のクラスを処理する必要がありますデータベースとのやりとり、そして残りのコードはこれらのクラスを使用します。

私は個人的にストアドプロシージャを使用するのが嫌いです。異なるデータベースサーバーをサポートする必要がある場合は、移植が苦しいでしょう。パフォーマンスの向上はそれほどありませんでした。ストアドプロシージャとC++の間で前後に移動します。

Answer 5

これらのクエリが時間の経過とともにどのように変化するかを考え、関連するC++コードがどのように変化するかを比較する必要があります。クエリが比較的コードから独立しており、変更の可能性が高い場合は、実行時に別のファイルからロードするか、代わりにストアドプロシージャを使用します。このアプローチでは、C++コードを再コンパイルせずにクエリを変更することができます。一方、C++コードにクエリが高度に結合されている場合、他のコードに変更を伴う可能性がある場合は、コード内でクエリを保持します。このアプローチは、よりローカライズされた変更を行い、エラーを起こしにくいものにします。

1）すべてのSQLコードがアプリケーション内に存在する場合、そのアプリケーションは、ロジックの観点に含まれるほとんどの自己がある：それは本当に依存

Answer 6

は、ここにいくつかのメモです。これは、あなたが現在のアプリケーションで行ったように良いです。スピードの面では、これらのクエリを実行するときにSQLを解析する必要があるため、これは少し遅くなる可能性があります（Prepared文などを使用した場合など）。

2）2番目の方法は、すべてのSQLロジックをストアドプロシージャとしてサーバーに配置することです。これは、1行かどうかにかかわらず、小さなSQL照会でさえ非常に好ましいアプローチです。 DALレイヤーを作成するだけです。パフォーマンス面ではこれは非常に良いですが、ロジックはC++アプリケーションとSQLサーバーという2つの異なるシステムに存在します。ストアドプロシージャの入力と出力をテンプレートコード（C++やそれ以外のもの）に変換してより簡単に使用できる小さなユーティリティアプリケーションを構築する必要があります。

3）上記2つを組み合わせたアプローチ。私はこのルートをお勧めしません。