Ruby で作成された中規模のアプリがあり、RDBMS をかなり頻繁に使用しています。コードが大きくなるにつれて、見苦しい SQL ステートメントがアプリ内のすべてのモジュールとメソッドに広がり、多くのアプリケーション ロジックに埋め込まれていることがわかりました。これが悪いのかどうかはわかりませんが、私の腸はこれがかなり醜いと言っています...
一般的にどの言語でも、SQL ステートメントをどのように管理しますか? それとも、多くの SQL ステートメントをアプリケーション ロジックに埋め込むことは、保守性にとって有害だと思いますか? なぜですか、そうでないのですか？
ありがとう。
SQL は、データベースにアクセスするための言語です。多くの場合、大規模なアプリケーションのデータ ストアへの API であると混同されます。実際、データ ストアとアプリの間に実際の API を設計する必要があります。
はいくつかのことを意味します。
テーブルに格納されたデータにアクセスするには、テーブルに直接アクセスするのではなく、データベース内のビューを経由する必要があります。
データ変更ステップでは、ストアド プロシージャでinsert/ update/をラップします。deleteこれには、ストアド プロシージャで制約とトリガーを処理し、何が起こっているかをより適切に記録できるという副次的な利点があります。
セキュリティのために、セキュリティアーキテクチャの一部としてデータベースセキュリティを含めます。すべてのユーザーにフルアクセスを提供することは、最良のアプローチではないかもしれません。
残念ながら、データベースを直接使用する単純なアプリケーションを作成するのは簡単です。それは、Java、Ruby、VBA などのいずれでも可能です。これがより大きなアプリに成長すると、メンテナンスの問題が発生します。
これを修正するための漸進的なアプローチをお勧めします。コードを調べて、厄介な select ステートメントがあるビューを作成します。おそらく、選択よりもはるかに少ないビューが必要であることに気付くでしょう (ビューは再利用できます - 良いことです)。
コードが変更されている場所を見つけて、これらをストアド プロシージャに変更します。私はエラー チェックのために常にストアド プロシージャからステータスを返し、ログ情報を何かと呼ばれるテーブルに入れsplogます_spcalls。
アプリのさまざまなユーザーの権限を制限したい場合は、これに興味があるかもしれません。
生の SQL ステートメントをコードに残すことは問題です。列の名前を変更するまで待ってください。これによりコードが壊れるすべての場所を見つける必要があります。
アプリケーションのアーキテクチャによって異なりますが、簡単な解決策は、各 sql をファイル qry.sql に保持することです。各 Ruby モジュール (または関連するコードを集約するために Ruby で使用されるもの) ごとに、これらのファイルを含むフォルダー SQL を保持できます。したがって、SQL フォルダー/ファイルのコレクションは、アプリケーションのデータ アクセス層を形成します。Ruby コードはビジネス層を提供します。データ モデルが変更された場合 (フィールド名など)、greps を実行して、変更が必要な sql ファイルを特定できます。とにかく、間違いなく SQL をロジック コードから分離してください。
これを Java で行う方法は次のとおりです。 データベースへのすべてのアクセスをカプセル化するクラスを作成します。実行する必要がある各クエリのクラスにメソッドを追加します。
ルビーの答えはこれに似ています。
はい、これは最適ではありません。メンテナンスは悪夢になります。基礎となる DB の変更が発生したときに、どのコードを変更する必要があるかを予測して判断するのは困難です。これが、データ アクセス レイヤー (DAL) を作成して、アプリケーション ロジックからの CRUD 操作をカプセル化することをお勧めする理由です。多くの場合、アプリケーション ロジックと DAL の間にビジネス ロジック層 (BLL) があり、ビジネス ルール/ロジックを適用します。
詳細については、Google の「データ アクセス レイヤー」「ビジネス ロジック レイヤー」、さらには「n 層アーキテクチャ」を参照してください。
アプリケーション ロジックに散らばる SQL ステートメントが気になる場合は、それらをストアド プロシージャとして実装することを検討してください。
そうすれば、プロシージャ名とそれに渡す必要のあるパラメータのみをコードに含めることができます。
他にも利点があります。一般的な利点は、複数のファイルで簡単に再利用できることです。
ストアド プロシージャの速度とセキュリティについては多くの議論があり、それについて決定的な答えが得られることは決してないので、ワームの缶を開けることさえしません。