問題を解決するためのソフトウェア (たとえば TFS) が存在する状況にあることは珍しくありませんが、何らかの理由でそれを環境内で使用することはできません。ソース コード管理ソフトウェアを悪用する方法があります。たとえば、不正な開発者が「自分の」サンドボックスからすべてのレポートを実行し始めるとします。また、バージョン管理ソフトウェアがすべての問題を解決するわけではありません。たとえば、コード内のコメントや命名規則については何も言うことはありません。
データベース ソフトウェアのメンテナンスを支援するための「標準」を次に示します。
バージョン管理ソフトウェアが許可されていない場合、変更履歴を説明するコメント ブロックがあります。次のようになります。
/*
* GSL 2013-06-08 Modified foo at Jean's request
* GSL 2013-06-01 Created
*/
これは、ビュー、ストアド プロシージャ、およびユーザー定義関数に適用されます。コメントなしで変更に気付いた場合は、「メールまたは直接会う」アプローチを使用して、遵守を甘やかします.
以下はバージョン管理には関係ありません。
命名規則: 異なる表にある同じものは、常に同じ名前になります。主キーも。一般に、複数形でテーブルに名前を付けてから、「s」を削除し、主キーの「id」を追加します。
列の規則: ほとんどすべてのテーブルには、主キー (テーブル名に「id」が追加された単数形)CreatedAtとCreatedBy列があります。後者は、「最後に行われたことは何ですか?」という質問に答えます。と「誰がダニット？」
列のプレフィックス: ソース列がデータベースの外部から取得されたテーブルの場合、プレフィックスを使用してそれらがどこから来たのかを示します。jl_telephonenumberジェーンのリストにあるものの電話番号のようなものです。
エラーの検出: ストアド プロシージャをtry/catchブロックでラップし、ローカルでエラーを処理しようとします。通常、ストアド プロシージャは変数statusとErrMsg出力変数を受け取るので、ステータス情報を呼び出し元に返すことができます。そして、発信者は常にステータスをチェックします。
インデント: これは宗教的なものであり、私には宗教があります。私が使用している非常に特殊なインデント スタイルで本を書いたことには、一定の利点があります。私は、特定のスタイルをすべての人に課すことはできないことを十分に知っています。ただし、コードは明確で、サブクエリ ブロックを互いに明確に区別できる必要があります。
テーブルの別名: 、、、、、、。a_ エイリアスは、問題のテーブルの省略形である必要があります。bcxyz
最後に (今のところ)、コードの正確性を本当に保証したい場合は、コード レビューを開始する必要があります。これは、週に 1 回 60 分の会議で、1 つのレポートを調べて、レポートのコーディングの側面について話し合うことになります。おそらく、そのようなレビューは、既存のレポートの欠陥を指摘することにより、非常に価値があることが証明されるでしょう.