SQLの変更をSQLファイルに追加するアプリケーションがあり、テストやその他の環境でインストール中に実行されます。だから25人くらいの人が働いていて、誰かが間違いを犯すとDDL、DML、時には構文エラーのようなテスト環境で壊れます。SQLファイルの検証 - SQL Validator
これでSQLファイルのクエリに対して実行計画を実行するSQlバリデーターを作成することを避けました。 SQL文は1行または複数行として記述されます。それらをフォーマットしてから、構文エラーやその他のエラーを見つけて報告しなければなりません。テストにインストールしている間は、時間がかかり、リワークする時間が長くなります。
ここでは、SQLファイルの手動レビューを行いますが、それ以降も、検出されないエラーやテストでのエラーはほとんどありません。
どのような提案も高く評価されます。
あなたはSQLバリデータが必要だと言いますが、おそらく必要なのはより良い開発プロセスです。
私が推測してみましょう - 誰もが働く単一の開発サーバーがあります。彼らはそこに変更を加え、何も破壊しないようにして、そのデータベースからSQL文を抽出し、それを他のサーバに適用します。
これはほとんどのOracle開発者の仕事です。それは痛みを伴い、拡大縮小しません。何十年も前に開発された単純なソフトウェア開発手法を使用するより良い方法があります。
バージョン管理を真実の単一のソースとして使用します。ほとんどのOracleショップでは、賞賛されたバックアップとしてのみバージョン管理が使用されています。ここで簡単なテストです - 開発サーバー上のすべてのスキーマを削除します。 5分でソースコードリポジトリからバックアップして実行できない場合は、実際にバージョンコントロールを使用していません。
ほとんどの哲学的な質問にお答えください。本当に理想的な製品のバージョンはどこにありますか？データベース製品を構築している場合でも、「開発データベース」ではなく、「バージョン管理されたテキストファイル」に答えなければなりません。
無制限のデータベースとスキーマ。これは聞こえるほど簡単です - すべてのOracle開発者とテスターは、デスクトップ上でOracleを実行します。次に、必要な数のインスタンスとスキーマを作成できます。私は多くのJavaプログラマがこれをやっているのを見たことがありますが、残念ながらほとんどのOracle開発者は不可能だと思っています。
自動テスト。自動単体テストは自信を与えます。今のように、あなたはコードに自信を持っているように思えます。 構文のエラーについては心配しないでください。これはプログラミング101の問題です。チームの全員が常にコードを構築してテストしている場合、エラーは大幅に減少します。物事はまだ時々壊れるでしょう - あなたは継続的な統合のような何かを加えることができますまたは絶えずビルドを壊す人々をちょうど恥ずかしい。
これらの3つの組み合わせは、究極のSQLバリデータです。あなたが正しいコードを持っていることを確認するためのバージョン管理。ローカルインスタンスを使用すると、コードのインストールと検証が容易になります。そして、検証を行うための自動テスト。