2

私の会社では、各データベース オブジェクト (ストアド プロシージャ、ビューなど) を個別の SQL ファイルとして保存し、そのようにソース管理下に配置しています。

これまで、バージョン管理されたファイル構造には非常にフラットなストレージ モデルがありました。

  • DatabaseProject
    • Functions
      • (すべての関数がここにあり、それ以上のネストはありません)
    • StoredProcedures
      • (すべてのストアド プロシージャがここに含まれます。それ以上のネストはありません)
    • Views
      • （同上）

大きな新しいプロジェクトのために、別のアイデアが思い浮かびました。プレハブのフラット リストではなく、件名ごとにこれらのファイルを保存してみませんか?

例えば：

  • DatabaseProject
    • Reports
      • (個々のストアド プロシージャ、ビューなど)
      • SpecificReport
        • (ここにオブジェクトが追加され、必要に応じてさらにネストされます)
    • SpecificApplication
      • (任意の深いネストを持つすべてのタイプの DB オブジェクト)
    • など……。

明らかな欠点は、このフォルダー構造がデータベース オブジェクトにいかなる種類の名前空間階層も課さないことです。組織専用です。したがって、重複した名前を持つオブジェクトを導入するのは非常に簡単です。データベースプロジェクトを調査し、名前の競合で死ぬには、ある種のビルドツールが必要です。

私が知りたいのは、バージョン管理されたファイル構造でアプリケーションのサブジェクトごとに SQL ファイルを整理するこの方法を試した人はいますか? それは価値がありました？私が説明したように、プロジェクトを監視するビルド ツールを作成しましたか?

4

3 に答える 3

1

SQLスクリプトを名前ではなく、トピックごとに整理するのが好きです。原則として、関連するアイテムを1つのファイルにグループ化することもできます。これの主な利点は次のとおりです。

  • ファイルシステム/IDEをファイルで乱雑にすることはありません（ファイルの多くは数行の長さです）。
  • 全体的なデータベース構造は、より直接的に示されます。

一方、特定のオブジェクトに関連するソースコードを見つけるのは難しいかもしれません...

重複する名前については、データベースを構築するための自動化されたスクリプトがあるため、発生することはありません。これをファイルシステムに依存することは、問題を探しています...

結論として、あなたの現在のルールは、ルールがまったくないよりもはるかに優れていると言えます。

于 2009-08-04T14:19:00.103 に答える
1

ビューまたは SP がどこで使用されているかが明確になるように、データベース オブジェクトの命名規則を定義する必要があります。

これは、アプリ モジュールを説明するプレフィックス、またはモジュール/機能の個別のスキーマ名のいずれかです。

ネスティングは不要で、VCS の名前はデータベースと同じように表示され、命名スキームに応じて適切に並べ替えられます。

于 2009-06-18T21:49:41.330 に答える