3

新しい Oracle スキーマとプロジェクト ディレクトリ内の依存ファイル (シーケンス、トリガー、DDL など) を最適に編成する方法についてアドバイスを探しています。ベストプラクティスがあるかどうか疑問に思っていますか？何かのようなもの...

database/
   tables/
      person.sql
      group.sql
   sequences/
      person.sequence
      group.sequence
   triggers/
      new_person.trigger

あなたの考えや私が見逃したかもしれない URL にペニー!

ありがとうございました！

4

4 に答える 4

3

オブジェクト タイプごとに DDL を格納するのは妥当なアプローチです。モノリシックな SQL スクリプトよりも、あらゆるものをナビゲートする方が簡単です。ただし、個人的には、DDL を関数ごとに整理した方がよいと思います。たとえば、会計システムを構築している場合、おそらく、買掛金を管理するための一連のオブジェクトと、総勘定元帳を管理するためのいくつかのコア オブジェクトに加えて、売掛金を管理するための別のオブジェクト セットがあります。それは、次のようなことにつながります

database/
  general_ledger/
    tables/
    packages/
    sequences/
  accounts_receivable/
    tables/
    packages/
    sequences/
  accounts_payable/
    tables/
    packages/
    sequences

システムがより複雑になるにつれて、その階層は時間の経過とともに自然に深くなります。この種のアプローチは、非データベース コードがソース管理に格納される方法をより自然に反映します。次のようなディレクトリ構造には、Java クラスの単一のディレクトリはありません。

middle_tier/
  java/
    Foo.java
    Bar.java

同じ種類のビジネス ロジックを実装するクラスを一緒に編成し、異なるビットのビジネス ロジックを実装するクラスから分離します。

于 2010-11-02T20:18:29.213 に答える
2

考慮すべき項目の 1 つは、「最新のみ」のスクリプトとして機能する SQL です。これらには、CREATE OR REPLACE PROCEDURE/FUNCTION/TRIGGER などが含まれます。最新バージョンを実行していて、以前にデータベースに存在していた可能性があるものについて心配する必要はありません。

一方、スキーマへの変更が展開するにつれて、CREATE TABLE で開始し、いくつかの ALTER TABLE が続くテーブルがあります。また、アップグレードを行っている場合は、いくつかの ALTER TABLE スクリプトを (できれば順番に) 適用することをお勧めします。

線が引かれている場所が本当に明白でない限り、私は「機能グループ化」に反対します。おそらく、あるグループに USERS テーブルがあり、別のグループに USER_AUTHORITIES があり、3 番目のグループに AUTHORITY グループがあるような状況にはなりたくないでしょう。

適切に分離している場合、それらはおそらく別々のスキーマにあり、スキーマを区別したいでしょう (異なるスキーマで同じオブジェクト名を持つことができるため)。

于 2010-11-02T22:08:49.430 に答える
0

私たちのプロジェクトでは、いくらか組み合わせたアプローチを使用しています。ルートとしてのプログラムのコアと、サブフォルダー内の他の機能があります。

root/
  plugins/
    auth/
    mail/
    report/

等

これらすべてのフォルダには、DDLスクリプトとDMLスクリプトの両方があり、ほとんどすべてを複数回実行できます。たとえば、すべてのパッケージがとして定義されているcreate or replace...場合、すべてのデータ挿入スクリプトはデータがすでに存在するかどうかをチェックします。これにより、何かをクラッシュさせる可能性があるとは思わずに、ほとんどすべてのスクリプトを実行する機会が得られます。

create table明らかに、このシナリオは、および同様のステートメントには適用できません。これらのスクリプトでは、指定されたファイルを抽出し、次のような特定のORAエラーで失敗しないように実行する小さなbashスクリプトを手動で作成しましたORA-00955: name is already used by an existing object。

また、すべてのファイルはディレクトリ内で混在していますが、拡張子が異なります。.seqシーケンス、.tblテーブル、.pkgパッケージインターフェイス、.bdyパッケージボディ、.trgトリガーなどです。

また、すべてのファイルのプレフィックスを示す命名規則があります。cl_oper.tblテーブルcl_oper.seqとcl_oper.trgシーケンス、トリガー、および言及cl_oper_processing.pkgさcl_oper_processing.bdyれたオブジェクトのロジックを使用できます。ファイルマネージャでのこの命名規則を使用すると、プロジェクトのロジックの一部のユニットに接続されているすべてのファイルを簡単に確認できます（オブジェクトタイプによるディレクトリのグループ化ではこれは提供されません）。

この情報が何らかの形でお役に立てば幸いです。ご不明な点がございましたらコメントを残してください。

于 2010-11-03T09:33:46.713 に答える
0

データベースディレクトリの下に「スキーマ」ディレクトリを追加した、オブジェクトタイプによる分割の配置は、私にとってはうまく機能します。

私は、追加の機能別分割レイヤーを持つソース管理システムを使用してきました。オブジェクトが多数ある場合、ソース管理ファイルをデータベースに表示されるオブジェクトと相互参照しようとすると、追加の検索が追加されます。通常、オブジェクトをタイプ別にグループ化する GUI ナビゲーター。また、オブジェクトをこのように分類する方法が常に明確であるとは限りません。

そのスキーマによって他のスキーマまたはロールに付与された権限付与用の「権限付与」ディレクトリを、権限付与対象者ごとに 1 つのファイルとして追加することを検討してください。「APPLICATION_USER ロールは常にスキーマ X のすべてのテーブルで SELECT を取得する」などの「ルールベース」の付与がある場合は、PL/SQL 匿名ブロックを記述してこのアクションを実行します。(何らかのアドホックな方法で付与された権限をリバース エンジニアリングしたくなるかもしれませんが、新しいテーブルやビューがアプリケーションに追加されたときに何かを見落としがちです)。

すべてのスクリプトの区切り文字を標準化すると、Ant などのビルド ユーティリティを使用してデプロイを開始した場合に、作業が楽になります。「/」(対「;」) の使用は、SQL ステートメントと PL/SQL 無名ブロックの両方で機能します。

于 2010-11-03T04:29:17.440 に答える