データベーステーブル/列ルール
いくつかのルールを事前に設定する新しいデータベース設計を作成しています。これらのルールを導入することがどれほど理にかなっているのかはわかりませんが、
各テーブルと列の名前は意味のあるものにする必要があります。テーブルまたは列の目的に関する情報を提供する必要があります。
テーブル名は27文字を超えてはならず、列名は30文字を超えてはなりません。
テーブル名は複数形です。例：
COMPANIES、EMPLOYEES、PERSONS、GENDERS、RELIGIONS、COUNTRIES、...各テーブルの主キーは_
table_name_ID_、つまりNUMBER(15)です。テーブル名は主キー列で単数形として使用されます。例：_USER_REQUESTS_テーブルの主キーは_USER_REQUEST_ID_です。テーブルまたは列の名前が制限を超える場合は、適切な省略形が使用されます。例：_
CMS_EXEMPTIONS_は、コンテンツ管理システムの免除を保持するためのテーブルです。トランザクションデータを保持するテーブルは_
_TRANS_で終わる必要があります。例：_COMPANY_TRANS_は、会社に関連するトランザクションデータを保持するテーブルです。各テーブルには4つのWHO列があります。
_
CREATE_USER NUMBER(15) CREATE_DATE DATE MODIFY_USER NUMBER(15) MODIFY_DATE DATE_外部キー関係である列は、参照されるテーブルの主キーとして名前が付けられます。例：テーブルが
COUNTRIESテーブルへの参照を持っている場合、参照している列はCOUNTRIESテーブルの主キーとして_COUNTRY_ID_とも呼ばれます。最初の規則（意味のある名前）のために参照列の意味が8番目の規則以外の場合は、意味のある名前の規則が適用されます。例：国籍と国の列は、_
NATIONALITY_ID_という名前ではなく、国籍を保持するために使用される場合、COUNTRIESテーブルとの関係があります。同じテーブルに関連するテーブルが複数ある場合、_
BIRTH_COUNTRY_ID_、_PASSPORT_ISSUE_COUNTRY_ID_などの異なる名前が付けられますテーブルがテーブル間のリレーションテーブルである場合、テーブル名には両方のテーブル名が含まれます。
意味のある名前を付けることは、常に命名における最初のルールでした。
- 各テーブルと列の名前は意味のあるものにする必要があります。
もちろん！
- テーブル名は27文字を超えてはなりません...
なぜ 27？
Oracle [11.2まで]は30をサポートしているので、他の3つで何をしますか？
その目的が何であれ、それを「標準」に追加する価値があるかもしれません。
...および列名は30文字を超えてはなりません。
列名cannot 30文字を超える...少なくともOracle 12まで。このため、この修飾は冗長になる可能性があります。
ただし、古いバージョン（または他のDBMS）をサポートする必要がある場合でも、これが必要になることがあります。
- テーブル名は複数形です。
OK。
- 各テーブルには主キー...があり、NUMBER（15）です。テーブル名は主キー列で単数形として使用されます。例：USER_REQUESTSテーブルには、USER_REQUEST_IDとして主キーがあります。
Natural Keyがテーブル、複合、その他にある場合は、最初にそれを使用することを検討します。テーブルにNatural Keyがない場合は、OK、サロゲートを使用します。
- テーブルまたは列の名前が制限を超える場合は、適切な省略形が使用されます。
受け入れ可能な略語の作成を文書化するか、さらには自動化することを強くお勧めします。そうしないと、誰もが違ったやり方をします。
- トランザクションデータを保持するテーブルは、_TRANSで終わる必要があります。
＃1と競合する可能性があります。
テーブル名を慣習やおしゃべりにまとめるのではなく、意味のあるのままにします。必要に応じて、外部のデータディクショナリツールでテーブルを文書化します。
- 各テーブルには4つのWHO列があります
それはいいです。
really重要なテーブルの場合、lastの変更以外の情報も保持する必要があるため、databaseですべての変更を記録する監査システムを実装しますレベル。アプリケーションレベルでそれを行わないでください。これにより、人々は隠れて潜入して回避することができます。
外部キー関係である列は、参照されるテーブルの主キーとして名前が付けられます。
最初の規則（意味のある名前）のために参照列の意味が8番目の規則以外の場合は、意味のある名前の規則が適用されます。
テーブルに同じテーブルに関連する複数のフィールドがある場合、それらには異なる名前が付けられます
これらは外部キーの賢明な規則であり、単純なケースが失敗するケースが存在する可能性があることを受け入れます。
良い計画。
- テーブルがテーブル間のリレーションテーブルである場合、テーブル名には両方のテーブル名が含まれます。
そして、これはすべてが落ちるところです。
テーブル名は30文字に制限されています。このルールを適用すると、テーブル名はそれぞれ15文字に制限され、no wayがあります。これらは意味のあるものになります。これを正確に実行する商用CRMパッケージを使用して、結果のテーブル名が単に恐ろしいものであることを証明できます。
すべてに意味のあるの名前を付けます。それは[ほとんど]非常に時間をかけて動作します。
これは holy wars のものです。正解はありません。さらに、これらはCIツールチェーンで（簡単に）実行できる種類の「ルール」ではありません。彼らはスタイルガイドです。施行はコードレビューとコンセンサスによって行われるため、影響を受けるすべての（または十分な）人々が同意し、決定に耐え、次世代と、ファウルと必然的に呼ばれる不信者に正当化できることを確認してください。
これらのルールが必要な理由を自問してください。私にとっては、コードを読みやすくする一貫性を課すことです。すぐに目がスタイルを読むことに慣れ、理解力が向上します。すべてのクエリとテーブルが独自のスタイルに従う場合、すべての読み取りでゼロから開始します。さらに、ルールは、オブジェクトにどのように名前を付けるかを決定するという認識の負荷を取り除きます。その決定はなされた。完了。重要なものに移ります。是非とも、この時間のかかる価値の低い活動にもう1秒間費やす必要はありません。そして最後に、優れたスタイルは、構造内で問題なく明らかになり、セマンティクスを明確にすることができます。
これらの対策により、あなたの提案は大丈夫だと思います。
ただし、いくつか提案があります。すべてのテーブルに数値の代理キーを強制する必要はありません。私はこれに触れました ここ 。
規則をクエリに拡張します。選択リスト（先頭または末尾のコンマ？）、結合（単一行または行ごとの句？）、サブクエリ、インデントには多くのバリエーションがあります。チームはこれについて一度だけ考える必要があります。一貫したレイアウトは、結合条件の欠落などのエラーを明確にするのに役立ちます。
WHOの列の規則が何度も使用されるのを見てきました。ほとんど役に立たない。オリジナルのクリエーターは、最新のアップデーターに対してどのような特別な意味を持っていますか？誰が1秒前に行を更新したかを知っているが、3秒前に誰が更新していないかを知ることが重要なのはなぜですか？
列FIRST_MAILING_ADDRESSとMOST_RECENT_MAILING_ADDRESSを含むPERSONSテーブルが表示された場合、データモデル作成者として、私たちは誤解を招くでしょう。同じことがこれらのWHOテーブルにも当てはまります。それらを独自のテーブルに正規化します。特定の列の値が時間の経過とともにどのように変化するかを知ることが重要である場合、これらの列も正規化されたテーブルにある必要があります。一般に、このパターンは temporal テーブルとして知られています。