🤹🏼 🧖🏿 🔃 Oracleでのオブジェクトの命名。横からの眺め 🧗🏾 🐹 ⛹🏿

「主なものについての古い歌」

「データベースオブジェクトの命名基準」と「コード設計ルール」は新しいトピックではありません。いずれにせよ、すべての開発チームは、このような標準とルールを開発または借用する問題に直面します。必要に応じて、このトピックに関する記事やプレゼンテーション、およびさまざまな契約の例やテンプレートをネットワークで見つけることができます。それらの多くは確かに有用であり、いくつかは完全ではありませんが、1つの小さな注意事項ではありません。開発者と開発者によって書かれています。

残念ながら、私の主観的な現実では、開発者は単なる一種の抽象化です。携帯電話の反対側にあるこのようなファントムは、数千キロメートルと3つのタイムゾーンから私を隔てています。私は彼らの集合的な脳に直接アクセスできません。悪用されたシステムのオブジェクトの形で、この脳によって生成された画像のみが利用可能です。

原則として、「アプリケーション」（アプリケーション管理者/技術者）と開発者の登録と命名の要望は、90パーセント一致しています。しかし、「読者」と「作家」の認識にはまだいくつかの違いがあります。それについてお話ししたいと思います。

この記事の目的：ソフトウェア開発者のチームがOracle DBMSに基づいた情報システムの設計で使用するデータベースオブジェクトの命名規則（命名規則-NCはコード規則に似ています）を開発し、次の要件を満たします。

NCは可能な限り一杯にする必要があります。すべてのタイプのデータベースオブジェクトの命名規則を含む
NCはできるだけ短くする必要があります。理想的なオプション：1 A4シート。

Oracle Databaseを選ぶ理由彼女は私に親しみ、親愛なる。そして、普遍性への主張で広大さを受け入れる試みは、私の歯と能力を超えています。このトピックでは、このトピックに関するBill Coulam、Steven Feuerstein、およびTom Kyteの記事の資料と、さまざまな情報システムの設計、開発、および運用におけるささやかな経験を要約しようとしました。

ネーミングへのさまざまなアプローチについて読むのが面倒で、このアプローチやそのアプローチを擁護する議論を歩き回る人は、単に記事を最後までスクロールすることができます。トピックに関する他の便利なリンクを見つけることができます。

あなたはまだここにいますか？しばらく待ってもスクロールを開始できませんでしたか？おめでとうございます。特別なボーナスがあります。この場所を離れることなく、「Oracle NC」ポスターをここからダウンロードできます。事実、私はすでに自分の記事を読んでおり（はい）、事前に警告しています。それは面倒で、一見するとあいまいなインセットテンプレートがたくさんあります。 1枚のシートにすべてのルールと例を手元に置いて、それを理解するのがはるかに簡単になります。

誰もがタンク内の主なものを知っていますが、誰もがholdすることはできません...

ITプロジェクトのためにNCを開発するという考えは表面上にあるように思われます。設計と開発におけるNCの要件への準拠も、天の恵みではありません。ただし、電気通信会社の課金システム市場におけるロシアの大手開発者によるソリューションの経験から、オブジェクトの命名とソースコードの設計の文化は実際には非常に低いことが示唆されています。原則として、私が義務的に研究したすべての決定は、4つのグループに分けることができます。

NCの兆候が完全にない（12製品中2製品）。これは悪夢です。そのようなシステムを操作することは、絵を下にしてパズルを組み立てるようなものです。多大な労力を費やして、相互接続とロジックの個々のスレッドのみをボールから引き出すことができます。そして、毎回、新しい問題で、もつれを再び解く必要があります。
1つのプロジェクトで異なるNCを使用する（12のうち3つの製品）。開発者がNCについて耳にし、独自のスタイルを開発し、それに従うことを学んだことはすぐに明らかです。問題は、1つのプロジェクトに対して開発者とスタイルが多すぎることです。そのようなソリューションの動作は、単一のモジュールを学習した経験が別のモジュールでは役に立たないという事実によって妨げられます。部品を知ると、全体の信頼できるアイデアを得ることができません。
初期バージョンでははっきりと見えていたNCは、松葉杖の山の下に埋められ、強力な圧力パッチで洗浄されました（12個中6個の製品）。最も一般的なオプション。彼らが自制できなかった同じ戦車。
システムのライフサイクル全体のすべての要件と制限に準拠してNCを明確に修正しました。（12個中1個の製品）。ここで彼女は応用男の夢です...

私はp.pの理由の分析を掘り下げたくありません。 1-3、私は事実を述べているだけです。私が望んでいるのは、パラグラフ4の「夢」への一歩を踏み出すことです。だから、始めましょう。

一般的な推奨事項

Oracle DBMS用に開発する際に覚えておくべきことと従うべきことから始めましょう。

Oracleのオブジェクト名は30文字に制限されていることに注意してください。徹底的に。自分からは願いだけを追加できます。「コードヒント」をサポートしていないアプリケーションを介してシステムで作業する人が気に入らないようにするには、慎重になります。オブジェクトの名前はできるだけ短くしてください。
オブジェクト名は数字で始めることはできません。コメントはありません。
オブジェクトに名前を付けるときに同じ言語を使用します。できれば英語。文字変換を避けます。私を信じて、 ORDERSと呼ばれるテーブルは、 ZAKAZと呼ばれるテーブルよりもよく知覚されます。その他。非常に頻繁に商用システムでは、略語の音訳を処理する必要があります。彼女も避けてください。 ソ連は SSSRよりも明確であり、 米国は 何らかの形でSSHAよりも明確です。
はい、ほとんど忘れていました。ラテン名でのみ使用してください！もちろん、これはばか向けの推奨事項ですが、SQLPLUSのテーブルからフェッチしようとして、私は一度夢中になりそうになりました。そして、すべて最後にロシア語のレイアウトに記号「e」があったからです。 PL / SQL Developerでは、名前を完全に入力する必要はありませんでした-コードヒントが機能しました。おもしろいことに、テーブルはこの形式で1か月以上生き続けており、私よりも前に誰も文句を言いませんでした。
システムを設計するプロセスで（サブジェクト領域を調べた直後）、識別されたすべてのエンティティを別のファイル（テーブル-用語集）に書き換えます。インターネットでのんびりするのが面倒ではありません-あなたのエンティティのほとんどには、長い間確立され一般的に受け入れられている英語の名前があります。用語集で修正してください。他のエンティティについては、適切な翻訳を行います。将来の略語についても同じことを行います。それから、最も重要なことは、同じ意味の要素には常に同じ名前を使用することです。
Oracleの予約語を名前として使用しないでください（すべての予約語のリストは、システムビューV $ RESERVED_WORDSから選択することで取得できます）。ところで、Oracleの特定の表現からのいくつかの単語は使用できません。しかし、直接使用が禁止されていないものもありますが、結局のところ、使用しない方が良いです。
オブジェクト名のトークンはアンダースコアで区切ります。 Oracleでは大文字と小文字が区別されないため、 MySuperPuperTableNameのような「ラクダ」は、ディクショナリで完全に読み取れないMYSUPERPUPERTABLENAMEに変わります。

わずかな余談
正直なところ、Oracleでは、オブジェクトの大文字と小文字を区別する名前を指定できます。たとえば、次のように：

create table "MyTable" (a number);

要するに、そのような倒錯を避けてください。

オブジェクトの命名規則

テーブル

テーブルの命名については、ビルコールハムの見解をほぼ完全に共有します。彼によって開発された標準は、開発者にとっても「エクスプロイト」にとっても、網羅的で実用上理想的です。ここでは完全な翻訳は行いません。基本的な点にのみ焦点を当てます。

そのため、Colehamは、テーブルに次の名前を付ける一般的な形式を提供します（中括弧には必須コンポーネントが含まれ、「直線」括弧にはオプションコンポーネントが含まれます）。

 [_][_]{}[_]

モジュールの下（Colema- システムグループの観点から）は、データベース内のサブシステムの名前を意味します。通常、2〜4文字の削減が使用されます。たとえば、「関税」モジュールのテーブルには接頭辞「TAR_」があり、支払モジュールのテーブルには接頭辞「PAY_」があります。「外国」のスキームで開発を行う場合は、追加のプレフィックスを追加して、オブジェクトを分離することをお勧めします。通常、組織の短縮名をプレフィックスに追加します。もちろん、これによりオブジェクトの名前が長くなりますが、プロジェクトツリーで「自分の」オブジェクトを明確に選択できます。このアプローチに戸惑うなら、モジュールコードの前に1つの文字を追加するだけで十分です（「ローカル開発者」は通常XまたはXXを好みます-OEBSの継承？！）。

グループは同じ目的で使用されます。論理的に接続されているエンティティをグループ化することができます（通常、グループ内の最大20個のオブジェクト）。また、2〜4文字が削減されます。システムグループと論理グループを使用すると、オブジェクトツリー内のエンティティをグループ化できるだけでなく、システム全体の開発と保守も大幅に簡素化できます。実際、特定のオブジェクトの名前を覚える必要はなくなり、モジュールと論理グループの略語を覚えておくだけで、コードヒントは必要なオブジェクトを簡単に見つけるのに役立ちます。

名前を使用すると、すべてが明確になります。これは、エンティティの実際の名前です。ビル・コールハムは単数形の使用を推奨していますが、個人的に私は複数形にもっと親しみ、より精通しています（Stephen Furstayn、こんにちは！）。スティーブンとビルの両方は、エンティティ名の略語を避けることを勧めています。例外は、8文字より長い単語です。

テーブルの目的を一言で表すことは常に可能とは限りません。この場合、習慣から外れた一部の国内の開発者は、単語の順序が一般的なものから特定のものへ、本質から財産へと変わるとき、私が自分自身を「販売受領規則」と呼ぶ規則を使用します。つまり「トイレットペーパー」、「ピクルスのキュウリ」、「トマトペースト」の代わりに「トイレットペーパー」。残念ながら、英語の名前ではほとんどの場合ひどいように見えます。 YELLOW_SUBMARINEとSUBMARINE_YELLOWを比較します。この場合、単一のテンプレートに依存する理由はありませんが、特定のコンテキストでより適切な順序を使用することをお勧めします。

ロールは基本的に、システム内のテーブルの目的（宛先のタイプ）です。 Colehamは約20の役割を選出しますが、私の好みでは、それらのいくつかは冗長です。私が使用するもののみを提供します：

_AUD-ベーステーブル（ジャーナルテーブル）の行の変更履歴を保存するテーブル。このタイプのテーブルの異なるシステムで、接尾辞_JN （ログ）と_HISTに出会いました。自身は接尾辞_AUDITを使用しましたが 、現在は_JNです。 _AUDはトリガーの名前で私によく知られています。
_LOG-アプリケーションメッセージコミットテーブル（ログテーブル）
_HIST-古くなったデータがアップロードされるテーブルをアーカイブします。このタイプのテーブルでは、接尾辞_ARCHを使用します
_TYPE-参照テーブル。行は一意の値のリストです。国内の開発者は、多くの場合、ディレクトリテーブルに_REFサフィックスを使用します。 _REFという単語は開発者の間で非常に人気があり、多くの場合タイトルコンポーネントの一部であるため、 _REF接尾辞も気に入っています。
_GT-グローバル一時テーブル。 Stephen Furstineは、接尾辞_TMPまたは_TEMPを使用することをお勧めしますが、これは、私見では、考え方と矛盾しています。ロシアのプログラマーは、 _TEMPトークンを使用して一時的な「ガベージ」をマークするのに慣れているので、 _GTと_GTのみです。

別のクラスで、Colehamは多対多の関係が実装されるテーブルを識別します。そのようなテーブルに対して、彼は次の命名パターンを提供します。

 [_]{/  1_/  2}

私が出会ったほとんどのプロジェクトでは、開発者はそのような関連テーブルに「意味のある」名前を使用していました。私自身はテンプレートを使用します：

 [_][_]{  1_}{  2}

この場合のテーブルコードは、リンクに参加するテーブルの省略形です（2〜4文字）。たとえば、この標準の教師の講義（ TEACHERS ）に参加する学生の接続（ STUDENTS ）を格納するテーブルは、 STUD_TCHRと呼ばれます。はい、一見反発的に見えますが、時間の経過とともに利便性を理解します。一見すると、テーブルを「束」として分類します（フルネームの代わりにコード/略語を使用しているため）。

テーブルの列（列）

名前の長さの制限から始めましょう-15文字以内（より良い-少ない）を保つようにしてください。外部キーを持つ制約、インデックス、および列の後続の命名のために、上部の制約に対するマージンが必要になります。

私のプロジェクトでは、次のテンプレートを使用します。

 [ _]{ }[_]

テーブルコードは、列が属するテーブルの略語（2〜4文字）です。このプレフィックスをオプションとして指定しましたが、ほとんどすべての列に使用します。例外は、特定のオブジェクト（ UPDATE_DATE 、 UPDATE_BYなど）のプロパティではなく、テーブルの抽象レコードの特定のプロパティの値を格納する「サービス」列です。

列の名前はそれ自体を表しています。別途、ルールについてのみ外部キーの名前の形成について言いたいと思います-それは子テーブルのコードと親主キーのフルネームで構成されます。

ロール -オプションのサフィックス。これは列の値型であり、この列のデータ型コードではないことに注意してください！ほとんどの場合、次のロール（値タイプ）を使用します。

_ID-代理キーオブジェクト識別子
_NUM-数値を含む文字列フィールド。
_CODE-エンティティの文字列キー（参照テーブルに固有）。
_DESC-エンティティの概要
_YN -Y（es）またはN（o）の値をとるCHAR（1）型のフィールド

多くの場合、テンプレート（具体的には、テーブルコード形式のプレフィックス）は冗長であると見なされます。しかし、さまざまなアプローチを比較できるため、私はそれを自分で選択しました。理由を説明します。

より読みやすいクエリ。接頭辞のある列によって、どのテーブルについて話しているかがすぐにわかります。多くの場合、開発者が列を修飾するのが面倒だということは秘密ではないため、接頭辞を持つ列の名前は「外部」クエリでの作業を容易にします。
例外（エラー）の診断が容易になります。もちろん、それらのほとんどは特定の列ではなく制約を参照していますが、ほとんどの場合、制約の名前は列名に基づいています。
システム辞書の予約語と一致する列名の確率が低下します。これは特に、NAME、ID、COMMENT、DATEなどの一般的な名前に当てはまります。その結果、開発者は他の冗長な文字の組み合わせを名前に追加する必要がなくなります。
弊社では、使用されたクライアントソフトウェアのほとんどがOracle Formsに基づいて開発されており、どのフィールドでもF1ボタンを使用してソース列の名前を確認できることがわかりました。フォーム上のオブジェクトをデータベース内のオブジェクトに即座に関連付ける機能は、システムの初期の知り合いやその後の操作に非常に役立ちます。

制限事項

Colehamは、この制限が適用されるテーブルのフルネームの形式のプレフィックスを使用して、名前付け制約を推奨しています。特に名前の長さごとに30文字という一般的な制限を考えると、この命名は不合理な無駄だと思います。したがって、フルネームの代わりにテーブルのコードを使用することが可能です。したがって、主キーについては次のようになります。

 [_][_]{ }{_PK}

以降、 モジュールおよびグループ制限プレフィックスは、関連付けられているテーブルから継承されます。これにより、大規模システムでの名前の形成における一意性の違反が回避され、モジュールの制限をグループ化するのにも便利です。

1つの列に構築された一意のキーの場合：

 [_][_]{ }{_UK}

コラムテンプレートにはテーブルコードが含まれていることを思い出してください。したがって、 UTL_PARAMS_REFテーブルのPRM_CODE列では、一意のキーはUTL_PRM_CODE_UKと呼ばれます

複数の列に構築された一意のキーの場合：

 [_][_]{ _}{CMP_UK}[_#]

COMP-この場合、 COMPOSITE （複合キー記号）を意味します。複数の一意の複合キーがある場合は＃（シリアル番号）が使用されます（正直なところ、この場合の正しい例は思いつきません）。

1つの列に基づく外部キー：

 [_][_]{ }{_FK}

外部キー列のフルネームには子テーブルと親テーブルの コードが含まれているため、 UTL_PARAM_VALUES テーブルのPVL_PRM_ID列では、外部キーはUTL_PVL_PRM_ID_FKと呼ばれます（ UTL_PARAMS_REFテーブルのPRM_ID列を参照）

複数の列で構築された外部キー：

 [_][_]{ _}{COMP_FK}[_#]

列レベルの制約：

 [_][_]{ }{_CK}

テーブルレベルの制限：

 [_][_]{ _}{COMP_CK}[_#]

インターネットで、 NOT NULL型の制約に名前を付ける必要性についての激しい議論にしばしば会いました。はい、私は怠慢に同意しますが、この概念を厳密に遵守する場合は、次のようにします。

 [_][_]{ }{_NN}

指数

私は通常、インデックスを3つのカテゴリに分けます。

キーベースのインデックス（プライマリおよびユニーク）
単一列インデックス
複合（複数の列に基づく）

キーベースのインデックス（プライマリおよびユニーク）は、対応する制限と同じ方法で名前が付けられます。

 [_][_]{ }{_PK} [_][_]{ }{_UK} [_][_]{ _}{CMP_UK}[_#]

単一の列に基づくインデックス：

 [_][_]{ }[_]{_IDX}

このテンプレートのロールは、インデックスタイプ修飾子を参照します。 Colemは、次の修飾子を使用することをお勧めします。

L-ローカルパーティションインデックス
G-パーティションテーブルのグローバルインデックス
B-ビットマップインデックス
F-関数ベースのインデックス
C-圧縮されたインデックス（圧縮された）
R-逆キーインデックス（キーの逆順のインデックス）
U-一意のインデックス

複数の列に基づくインデックス。 Colehamは次の形式を推奨しています。

 [_][_]{ }{_COMP}[_]{_IDX}[#]

Colemパターンを特別なケースと見なし、インデックス名のすべての列（これが長さの制限に違反しない場合）を常にリストしようとします。

 [_][_]{ _}{ }[_]{_IDX}

制限のためにCOMP修飾子に制限されているのに、インデックスには使用しないようにしているのはなぜですか？ただし、複合制約はルールではなく例外です。通常、それらはそれほど多くありません。また、違反に関するエラーのあるメッセージはあまり見られません。複合インデックスは別の問題です。まず、それらの多くがあります。第二に、多くの場合、テーブルごとに複数あります。そして第三に、アプリケーションの開発者と管理者は、クエリプランを確認しながら絶えず彼らと協力します。

トリガー

この記事では、DMLトリガーのみを検討します。これは、他のすべてのタイプの方が開発者ではなくDBAの責任であると考えているためです。次のルールでトリガーを呼び出します。

 [_][_]{ }[_/]_{B|A|C (I|U|D)[S]}[_#]

略語B 、 A 、 C （ BEFORE 、 AFTER 、 COMPOUND ）は、トリガーの「モーメント」を決定します。 I 、 U 、 D （ INSERT 、 UPDATE 、 DELETE ）-応答イベント。 S （ STATEMENT ）-操作の「レベル」を決定します。

私のプロジェクトでは、2つの「典型的な」トリガー（ロール）を区別しています。

AUDIT-ジャーナル内のメインテーブルへの変更をコミットするトリガー（ UTL_PRM_AUDIT_AIUDなど ）
INIT-サロゲートキーの生成と列のデフォルト値の入力を行う「初期化」トリガー（ UTL_PRM_INIT_BIなど ）

視聴回数

ビューの命名規則は、テーブルの命名規則と変わりません。唯一の願いは、このオブジェクトが単なる表現であるというサインを名前に含めることです。ここでのアプローチは異なる場合があります。名前の接頭辞の形でこの症状に出会いました。たとえば、 V_またはV $であり 、Oracleシステムビューのようなものです。個人的には、サフィックスを使用します：

$ V-通常のビュー用
$ MV-マテリアライズド

しかし、私はあなたに助言しません。区切り記号としてのドル記号は習慣の問題です。これは私の目の「アンカー」であり、テーブルとビューを区別できます。これらのアプローチを客観的に見ることはできません。したがって、Ferstayn（接尾辞_Vおよび_MW ）のように、「アンダースコア」記号に反対するものは何もありません。

シーケンス

シーケンスをサフィックス_SEQで他のオブジェクトと区別し、次のルールで命名することをお勧めします。

 [_][_]{  |    | }{_SEQ}

テーブルコード （ テーブルの省略名は2〜4文字）は、テーブルのサロゲート主キーを生成するシーケンスに使用されます。

列の名前 （ここでは、テーブルのコードが含まれています）を使用して、主キーに含まれていない列の値を生成します。実際、これは私が実際に使用しない退化したケースです。シーケンスが主キー値の生成に使用されていない場合-名前では、このシーケンスの目的を反映しようとします。

たとえば、 INTERNET_LOGINSテーブルILG_SEQの主キーを生成するためのシーケンスを呼び出し、特定のインターネットアカウントのログインを生成するためのシーケンスはLOGIN_SEQです。

同義語

シノニムは、参照するオブジェクトと同じ方法で参照されます。

種類

タイプごとに、明確に形成された意見はありません。これらのオブジェクトに名前を付けるためのさまざまなアプローチに出会いましたが、どのアプローチが自分に近いかを完全に決定することはできませんでした。ここで私に否定的な反応を引き起こさないものを説明します：

  [_][_]{}[_ ]T

このテンプレートは、Coleamが推奨しています。型コレクションの記号は、記号Tで識別されます。したがって、単一オブジェクトの型には常に接尾辞_Tが付き、コレクション型は_TTです。たとえば、 UTL_PARAMETER_T 、 UTL_PARAMETER_TT 。

 [_][_]{}[S]_TYP

ここで、 Sは複数を表し、サフィックスTYPはデータベースオブジェクトを型として修飾します。たとえば、 UTL_PARAMETER_TYP 、 UTL_PARAMETERS_TYP 。コレクションのサインが強調表示されておらず、目がそれに固執していないため、私はこのアプローチが最も好きです。

 [_][_]{}_{OBJ | TAB}

この表記では、データベースオブジェクトの名前がOBJまたはTABで終わる場合、オブジェクトはタイプです（ TABはコレクション、 OBJは単一のオブジェクトです）。たとえば、 UTL_PARAMETER_OBJ 、 UTL_PARAMETERS_TAB

ソフトウェアモジュール

プログラムモジュールのコードを設計するための規則別の記事を選びたいと思います。 Coleamが提案するテンプレートを次に示します。プロシージャパッケージの場合、Billは次のルールを使用します。

 [_][_]{/}[_. ][_PKG]

NC Coleamに関しては、 機能修飾子 （私にとってはサブグループという用語がより理解しやすい）を使用して、リファクタリングのためにいくつかの機能を個別のパッケージに分離しています。これが論理グループの追加レベルであるとだけ言ってみましょう。たとえば、 UTILパッケージには、数字と文字列を操作するための関数が含まれていました。 UTIL_NUMBERとUTIL_STRINGの 2つに分割されました 。

PL / SQLで開発する場合、スペシャリストは他のパッケージの機能と手順を常に操作します。コードが大きく見えないように、パッケージの名前が不必要に長くなるのを避けるようにします。したがって、サフィックス_PKGは、パッケージの名前がスキームの別のオブジェクトの名前と一致する可能性がある場合にのみ使用します。

個々の手順と機能について、Colehamは次のテンプレートを推奨しています。

 [_]{/}

アクションとは動詞（ GET 、 SET 、 ASSIGN 、 RUN ）を意味し、目標とは実行する必要があるものです。私の側では、開発中はパッケージ外のプロシージャと関数をまったく使用しないようにします。さらに、同じ関数は、それが機能するオブジェクトによってグループ化されることが多いため、通常はテンプレートを使用します

 {}[_]

したがって、コードヒントはプロシージャをオブジェクトにグループ化します： PARAM_GET 、 PARAM_SET 、 PARAM_CHECKなど。

おわりに

約束どおり、私は自分の「Oracle NC」ポスターへのリンクを引用します。

決して誰にも私の規則と基準を課すことはせず、それらの使用を主張しない。 NCの存在とチーム内での要件の遵守は、良いスタイルであると考えています。これは、開発者の「礼儀正しさ」であり、だれがその後システムを使用するかを示します。

あなたのプロジェクトで頑張ってください。

PS注意深い読者は確かに私の小さな欺certainlyに気づいた。この記事の最初の目標は決して達成されませんでした。すべてのタイプのOracle DBMSオブジェクトがこの記事で説明され、NCポスターに存在するわけではありません。さて、この欠陥を修正する機会があります。 NCポスターの「ソース」をダウンロードして、目的と目的に合わせて編集できます。

この記事では次のソースが使用されています。

Steven Feuersteinのブログとその命名規則とコード標準
Oracle Naming Standard Bill Coulam
Tom Kyte Blog Ask Tom ...

フォーラム資料SQL.RU

Oracleでのオブジェクトの命名。 横からの眺め